"Aren't You Scared OpenAI Will Just Build This?"

Every founder building anything adjacent to AI gets this question, and I get a database-flavored version of it constantly. "Aren't you scared Anthropic or OpenAI will just build safe database access into their product and put you out of business?" Sometimes it's an investor pressure-testing. Sometimes it's a friend who means well. It's a real question and it deserves a real answer, not a brave face.

So here's how I actually think about platform risk, including the parts that genuinely keep me up.

The honest version of the fear

Let me not minimize it. I'm building on top of a layer controlled by a few enormous, fast-moving companies. They could decide database access is core enough to build natively. They have more engineers, more distribution, and a direct relationship with every user I'm trying to reach. If they ship a good-enough version bundled into the thing people already use, "good enough and already here" beats "better but separate" for a lot of buyers. That's not paranoia. That's just how platforms eat features.

Anyone who tells you platform risk isn't real is selling something. It's real. The question isn't whether it exists. It's whether the specific thing you're building is the kind of thing the platform wants to own.

What platforms actually build vs leave alone

Here's the pattern I've convinced myself of, watching this play out across a lot of ecosystems. Platforms build the things that make their core product more valuable to everyone. They leave alone the things that are someone else's responsibility, someone else's liability, or too specific to a customer's environment.

A model company's core product is the model and the client around it. They'll absolutely build the connective tissue that makes the model more useful generically — better tool-use, better context handling, the protocol itself. They are much less eager to build the thing that sits between a customer's production database and the model and takes on the liability when a query goes wrong. That's not model work. That's database-access-governance work, and it lives in the customer's infrastructure, touches the customer's most sensitive data, and carries the kind of risk a platform doesn't want on its own balance sheet for someone else's database.

The tell is the liability. Platforms love features. They're allergic to owning your security boundary to your data. "Connect the model to a database" is a feature they might ship a thin version of. "Be the trusted, audited, permissioned layer that's accountable when something touches production" is a responsibility, and responsibilities to someone else's data are exactly what big platforms prefer to leave to specialists.

The thin-version reality

I also think the likely outcome isn't "they don't build it." It's "they build a thin version, and the thin version helps me."

A native "connect to your Postgres" feature in an AI client raises the whole category's awareness. It teaches the market that yes, you can connect your database to your agent, this is a thing people do. Most users who try the thin version and have a real production database quickly hit the questions the thin version doesn't answer: how do I make sure it can't write, how do I scope which tables, where's the audit log, how do I do this across five databases and a team. That's the moment the specialist exists for.

The platform shipping a basic version isn't the asteroid. It's the top of the funnel. I'd rather compete in a category OpenAI legitimized than evangelize an empty one alone.

Where the fear is actually warranted

I don't want to talk myself into total comfort, because there's a version of this that does hurt.

If my entire product were the thin version — just "run the query the model wrote" with no real governance, no multi-database story, no liability I'm taking on that they won't — then yes, the platform building it natively would end me, and it would deserve to, because I wouldn't have been adding anything they couldn't. The defense against platform risk isn't hope. It's making sure the thing you do is the thing the platform structurally doesn't want to do. The deeper into "trusted boundary to the customer's sensitive production data" I build, the less it looks like something a model company wants to own, and the more it looks like the part they'd rather point at a partner for.

That's the bet. Not that they can't build it. That they won't want to own the part that matters, because owning it means owning the liability, and the liability is the moat. I think it's a good bet. I'm also not naive that it's a bet, and on the days the question stings, it's because the honest answer is "I've positioned against it, not eliminated it." That's the real answer, and any founder who gives you a cleaner one is bluffing.

If you want to see the version that's deliberately built to be the part platforms don't want to own, that's QueryBear. But the framing is the transferable part: don't build the feature the platform wants. Build the responsibility it doesn't.