Our view on data warehousing
The warehouse was never the hard part.
Storing data stopped being difficult some years ago. Every serious platform will hold whatever you have, query it quickly, and scale further than you will ever need. That problem is solved, and it is not the one costing you money.
Snowflake is the right answer to a question most companies do not have
Snowflake is a great product. I am a shareholder, and I believe in it as a product with real value. It is also typically overkill, and not price effective, in the mid-market space. If you are dealing with petabytes of data, you should go to Snowflake, there is no doubt about it. But most solutions are not that.
Petabyte-scale analytics is a real problem and Snowflake solves it well. Most mid-market companies are nowhere near that scale, and they end up buying an architecture sized for a problem they will not have, priced on a model that charges them for using their own data.
What actually costs you
Once the data is stored, two questions remain, and neither is a storage problem.
Getting data in. Pipelines from systems that were not designed to share, running on a schedule, failing loudly rather than silently when a source changes its schema. This is where engineering months go.
Getting data out to the right people. Not a dashboard for your analysts. Access for a customer, a supplier, a distributor, a rep, each seeing their own slice and nothing else. Row and column level, enforced, auditable.
The second one is where most warehouse projects quietly stop. The data is in there, correct, and reachable by six people in the building.
Three good platforms, one shared assumption
We do not resell any of these platforms and we are not a partner to any of them. What we have is a working understanding of all three, and something more useful: we have watched clients and prospects try to solve this problem with each of them, and we have inherited the result. What follows is not a ranking.
Snowflake
The standard for large-scale cloud analytics.
- Genuinely excellent at scale.
- Separates storage from compute.
- Mature ecosystem, deep tooling, large talent pool.
- Consumption pricing means cost rises with use, which penalizes the behavior you were trying to encourage.
- No native API out of the box.
- There is an ORM connector, but no layer between the user and the database, so any application access has to be built.
Microsoft Fabric
The unified data platform for organizations already on Microsoft.
- Deep integration with the Microsoft estate.
- Bundled economics if you are already licensed.
- An API exists, unlike Snowflake.
- The API is difficult to set up.
- Permissioning user by user is harder still, and that is the exact operation an external-facing warehouse depends on.
Supabase
Warehouse and API layer in one, built for developers.
- Solves the two things Snowflake and Fabric leave you to build.
- The API layer is there, and permissioning is handled properly.
- Strong developer experience.
- No interface. It gives you a back end and expects you to build the front end yourself, which is the largest remaining piece of work.
The pattern underneath
Supabase is the closest thing to what we do, so it is the fairest comparison to make.
That is the whole distance between them and us. Supabase hands a developer a warehouse with permissions and an API, which is genuinely most of the way there. What it does not hand anyone is the thing a non-technical user opens: the forms, the dashboards, the screens a supplier or a distributor logs into. Someone still has to build that, and building it is a project rather than a configuration.
Read the three together and the same shape appears. Snowflake gives you the warehouse and leaves the access layer to you. Fabric gives you an API and leaves the permissioning to you. Supabase gives you both and leaves the interface to you.
Each of them stops one step before the thing your users touch. And that last step is not a small one: it is permissions, it is an interface a non-technical person can use, and it is the part that has to work for people outside your company.
Every one of them assumes the hard part is finished. The hard part is the last mile.
Paying to use your own data
There is a second problem, and it is structural rather than technical.
It is the same model as HubSpot and Salesforce in the CRM world. They win when you scale, and they win again when you are inefficient. A badly written query costs you money and earns them money. Storage, compute, querying, every one of those is a line where your mistakes turn into their margin. And mistakes compound. At small scale you never notice. At real scale the bill grows faster than the business does, and you are the one who built it.
Consumption pricing means the bill grows when the platform gets used. That is defensible as a business model and corrosive as an incentive. The moment your warehouse becomes genuinely useful, someone starts asking whether that dashboard needs to refresh hourly, and whether the supplier portal should really be open to all four hundred suppliers.
You end up rationing the thing you spent a year building. We think the right model charges for the platform, not for using it.
AI makes this sharper in both directions
AI will genuinely help here. Query optimization is a well-shaped problem for a model: spotting the missing index, rewriting the expensive join, flagging the report that scans an entire table every hour because nobody has looked at it since 2019. Alerting and notification are the same shape. That is the direction we are building toward, with internal DBA agents that watch the warehouse rather than waiting for someone to complain about it.
The same capability cuts the other way, and on a metered platform it cuts expensively. An agent that can write a query can write a thousand of them. It does not know that each one has a price, and it has no reason to prefer the efficient attempt over the third rewrite. Turned loose on a consumption-priced warehouse, AI is a very fast machine for converting your inefficiency into someone else's margin.
A foundation you are not renting
We think the mid-market needs a free, open-source foundation underneath all of this. Not because open source is cheaper, though it is, but because a foundation you do not own is a foundation someone else can reprice.
Co-Wright is built on PostgreSQL, the same base Supabase uses. What we have spent years and a substantial share of our R&D budget on is the set of gaps that base leaves open: the permissioning, the API layer, and the interface a non-technical person actually opens.
Where that leaves you
If you are choosing a warehouse, the storage question is the easy one and every serious platform passes it. The questions worth asking are the ones that come after: how does data get in, who can see which parts of it, how do people outside your company reach the slice that belongs to them, and what does it cost you when the answer is "more of them, more often."
Those are the questions Co-Wright was built around.