AI made writing code more than ten times faster. Most established software companies captured 20–30% of that, because writing code was never the bottleneck — handoffs, review queues, decisions that sit for days and knowledge only one person has are. Speed up one step and everything else still runs at human coordination speed.
So we built the Flint services from scratch, without the gatekeepers and without the tribal knowledge. AI does the work under human supervision, and the reliability bar is held by evidence rather than by sign-off: every failure mode is a drill that breaks the system on purpose, and every guard has to be shown failing when it is removed. It is the same reason operations are part of the product — failover, certificate rotation, rebalancing and metering are built to run without an operator, and the knowledge of how to run them ships with the software instead of living in an ops team's heads.
It runs on NVMe SSDs, not RAM: holds your whole working set, survives restarts and failovers, scales to 100 TB+ per cluster behind a single endpoint, and is priced by capacity.
Repeat reads of the same S3 data stop going to S3 at all, up to a size
limit you control. On Spark over TPC-DS, with the tier on its own box,
that was about 2× faster overall — 1.9× to
2.3× across four runs, and within a run 1.3× on a
bandwidth-bound scan against 2.8× on the selective queries, because
the win is in request latency rather than throughput. Which of those
your jobs look like decides your number. On the training shape —
one large shard re-read every epoch, in small reads — it was
5–7× from the second epoch on, and the epoch that
fills the cache is not slower than not caching at all. The cache lives in
one shared tier, not on each worker's local disk, so a Spark
job and a PyTorch job over the same dataset pay S3 once between them.
A library, not a service: one line of configuration, and your
s3a:// paths do not change. It works with any
Redis-protocol cache, self-hosted or managed — though at dataset
scale that tier wants to be disk-first rather than RAM, which is what
Flint Cache above is for.
Every version of every row is kept, so a snapshot read needs no copy and a clone is a pointer move: a full-size copy of production in a second, adding no storage until you write to it. Speaks the DynamoDB API, so an unmodified AWS SDK keeps working, in an object store you control.