How we got here

There was a time when adding a database to your stack was a decision.

It meant a procurement conversation. A capacity plan. A DBA who owned it. A security review. An onboarding runbook, and the person who had to write it. All of that was friction, and everyone hated the friction — and the friction was quietly doing a job nobody noticed. It was due diligence. Every piece of your stack had to earn its place before it got one.

Then the cloud made adding things free.

Not free to own — free to add. A new database is a few more lines in a CloudFormation template. A new queue, a new cache, a new vector store, a second warehouse: a few more lines each. The cost of adding collapsed to nearly zero. The cost of owning — the bill, the attack surface, the 3am page, the thing that breaks because a dependency three layers away changed under you — stayed exactly as high as it ever was. It just got harder to see.

We celebrated this. We called it velocity.

And now AI removes the last bit of friction that was left. The human who at least had to type the lines doesn't type them anymore. The model adds the Redis because production systems have a Redis. It adds the second warehouse because the pattern says production looks like that. Nobody decided. The stack grows because growing is frictionless, and every line of infrastructure-as-code becomes a decision that no human actually made.

This is how the enterprise stack got the way it is. Not through bad engineers. Through the steady, celebrated removal of every constraint that used to force a moment of thought.

The enterprise stack is a complex pile of always-on servers and libraries — most of which nobody chose on purpose, all of which bill you whether you use them or not.

Flat-stack is the opposite.

What flat-stack is

Flat-stack means using as close to nothing as possible. Almost no running computers. Almost no moving parts. Less to pay for. Less to break. Less to defend. Where the enterprise stack adds by default, flat-stack subtracts by default — and makes everything that survives justify its place.

This is not nostalgia, and it is not a complaint about the cloud. Just the opposite — the cloud is the reason flat-stack is possible at all. Scale-to-zero. Ephemeral compute. Cheap object storage you can read directly. The same code running in three places without a rewrite. None of it existed before the cloud invented it. The very primitives that let the enterprise stack bloat are the primitives flat-stack is built from. We can run it on prem, in Docker, on a laptop today — but we could never have gotten here without the cloud.

So the cloud was never the enemy. It is a tool. The difference between the enterprise stack and flat-stack was never whether you use the cloud — it's whether you use it to add without thinking, or to subtract on purpose.

We build with AI every day. We ship to AWS and Azure. We are not romantic about the old enterprise paradigms, and we are not evangelists for the new shiny ones. Flat-stack is simply the discipline the cloud deleted, put back — without giving up the speed the cloud gave us.

It is a way of building where every dependency is a decision someone made on purpose, where the balance sheet is treated as a real stakeholder in the room, and where the default answer to should we add this? is no, until proven otherwise.

Change is the only constant

Nothing about your business will stay still. You'll enter a market with data-residency laws you didn't have last quarter. You'll acquire a company and inherit a second stack overnight. You'll add ten times the customers, or a new product line, or a regulation will land, or the CFO will need the number cut by Friday. The business changes. It always changes.

And we do not change for the sake of changing — a newer warehouse is never the reason. We change for exactly one reason: the business needs us to. The business is the driver; the stack just has to follow.

That is what agility is for. Not being light, or first, or loudest about the new thing — that's fashion. Agility is keeping your center of gravity low, so that when the business moves, the technology moves with it instead of becoming the anchor that holds the business in place. A fighter in a low stance is hard to knock down and can move in any direction. A tower goes up fast and comes down in a strong wind.

Here is the subtle part: data has gravity — and that's fine. Data is mass, and mass pulls everything toward it. You want your data in one place; one source of truth beats a dozen drifting copies. Centralizing the data was never the mistake.

The mistake is locking that data inside a proprietary, always-on engine that owns the only door to it. Your data ends up somewhere you can't touch without paying the keeper who sits on top of it — every query, every export, every look, on their terms and at their price. The warehouse stops being a tool you use and becomes the gate standing between you and data you already own.

Flat-stack keeps the data in one place too. It just insists that the place be yours — open storage like S3, open formats anyone can read, reachable directly by the gateway, by your tools, and by you — with the warehouse as one consumer of that data, woken only when you genuinely need its horsepower. Flat means you get to touch the data too.

You cannot repeal data gravity, and you shouldn't try. But you do not have to hand the keys to your own data to the engine sitting on top of it.

That is what the name means. A stack is vertical — things piled on things, top-heavy, your own data held at the very top of someone else's tower, where you have to climb, and pay, to reach it. Flat-stack lays it down. The data sits low and in the open, close to whoever needs it. The heavy engine is engaged only when it truly must be. Your center of gravity stays low — and a low center of gravity is what lets the business move without the technology fighting it every step.

The North Star

What we promise the people who use Airbrx.

Flat-stack is not an aesthetic. It is the only architecture we have found that lets us promise an enterprise four things at the same time — without asking them to change a single workflow:

Their costs go down. A stack with almost nothing running has almost nothing to bill. We don't optimize the warehouse; we keep it asleep.

Their data gets faster. The fastest query is the one that never has to wake the warehouse at all. Served from a predictable key, the answer is already there.

They get precise control. A system built on reproducible keys is a system you can actually reason about, govern, and audit. Predictability isn't just cheap — it's controllable.

It stays secure. Every dependency you don't take on is an attack surface you don't have to defend. The smallest stack is also the safest one.

The enterprise stack made all four of those a tradeoff — pick two, pay for the rest. Flat-stack makes them the same decision.

The Southern Cross

How we build it.

  1. Do not wake the Beast. The warehouse bills you precisely when it runs — so don't run it. Answer from a predictable key, not a fresh query. A sleeping Beast doesn't bill.
  2. Keep your center of gravity low. Data belongs in one place — and that place should be yours. Open storage you control, in formats anyone can read, reachable directly — not locked inside an engine that rents you the only door to your own data. Keep it low and open, and you can follow the business anywhere. Pile it at the top of someone else's tower, and you pay to climb.
  3. The balance sheet is the product owner. Don't start with a technology and hunt for a problem. Start with what it costs the business and build backward. Every architectural decision is a financial one — treat it like one.
  4. Security, availability, and resilience are not features. They are the foundation, and they fail together. Security at the gateway, never bolted on. Availability no single vendor can take down. Resilience through fewer moving parts — every part is a part that can break. A solution that fails any of the three isn't a solution. It's a liability with good marketing.
  5. Every dependency is a decision. A library you import is someone else's code, someone else's exploits, someone else's outages — running inside your walls. Sometimes worth it. Usually not. If twenty lines you understand will do, write them: a function you understand always beats a dependency you don't.
  6. Build it stateless. Build it to scale to zero. Instances are cattle, not pets — swap one out and nothing notices. Stateless, portable, scale-to-zero: it runs on a laptop or any cloud, no warm-up choreography, no idle compute burning money and carbon while it waits for traffic that never came.
  7. No shiny objects. New is not a feature. Proven, portable, and replaceable are features. A fifteen-year-old battle-tested tool beats a bleeding-edge one still looking for a problem. We are not impressed by novelty. We are impressed by uptime.
  8. Modernization is baked in, not bolted on. Respect what works; replace what doesn't. Modernization is incremental and continuous — a habit, not a project with a budget and a steering committee.
  9. Document your schemas. Flat-stack runs on predictable, consistent data objects. Document them so they get reused instead of rebuilt. A documented schema can move. An undocumented blob is an anchor.
  10. Thank you; have a nice day — and go scale something down to zero.

The Flat-Stack Manifesto is the public edition of the engineering doctrine we build Airbrx by.