When to use SFlat
SFlat is a schema-first, line-oriented flat-file format for typed records, deterministic interchange, and optional Payload data such as large text or binary blobs.
Good fit
- Typed tabular exchange. Use SFlat when CSV's lack of types and schema causes parsing bugs or ambiguous values.
- Schema and validation in the file. SFlat files carry structured header metadata before typed records.
- Rows with large text or binary blobs. The Payload profile supports large strings and binary/BLOB data via base64/DEFLATE payloads.
- Deterministic pipeline output. Canonical UTF-8, LF-only bytes make diffing, hashing, and reproducible generation more reliable.
- Integrity checks or fast seeking. Body byte counts, SHA-256 body hashes, and sparse indexes help verify content and locate records.
- Conformance-focused interchange. SFlat is useful when an exact canonical byte layout matters across implementations.
Not a fit
- Deeply nested documents. Use JSON, YAML, or Protobuf for hierarchical data; SFlat is flat and record-oriented.
- Very large analytical workloads. Columnar formats such as Parquet are far more efficient for column-oriented analytics.
- Free-form prose or documents. Markdown or a word processor is better for human-authored narrative content.
- Mature ecosystem needs today. SFlat is experimental, pre-1.0, and the reference implementation is not yet public.
- High-volume append-only logs. A purpose-built streaming log format is usually a better match.
- Throwaway ad-hoc data. CSV or JSON may be preferable when ubiquity matters more than schema, types, or canonical bytes.
These guidelines are illustrative for the evolving SFlat v0.2 draft, not guarantees of suitability for every system.