Hacker News Reader

Comment by klabb3 | Hacker News Reader

I have followed a lot of these projects because I have clients with persistent state and synced state too, as well as realtime needs. Anyway, this passes the smell test imo. It’s solid engineering and built from first principles, reusing the right pieces. So congrats!

My concern with DB startups is always the business model. There’s a massive tension between open source and a sustainable business which is much more prevalent with deeply technical products. So either it’s too open and dies because aws eats their lunch or it’s too closed to be useful for self-hosting, or too complex to self-host, or priced too high for small players. What’s the strategy to build/grow the business in the short-medium term?

View on HN

It doesn't always work, but I like the SQLite model: the core offering is free and open source, but enterprises can pay for things like

* Professional support, including on-prem hosting when applicable

* Additional features that enterprises care about (encrypted databases, SSO)

* Compliance documentation/certifications

How big of a business is SQLite?

Maybe SQLite isn't that big, but Red Hat makes billions of dollars of annual revenue. GitLab is a public decacorn (or was one yesterday, anyways). Those are good businesses, and I'm pretty sure a good chunk of us run software from both of these.

It’s a one man company run by Richard Hipp.

Big enough to keep the developers happy to keep working on it. That is all that matters.

This is how DuckDB is structured too:

DuckDB Labs: The core contributors. Instead of developing features that will be behind a paywall, they provide support and consulting.

DuckDB Foundation: A non-profit that ensures DuckDB remains MIT licensed.

0 - https://x.com/thisritchie/status/1797962367571239309

FWIW SQLite has 3 developers, and I don't think it's even full-time for all of them.

This can work because SQLite is deliberately a very small yet very high impact project.

Very few projects (unfortunately) can boast that.

What if the DRM/license was based around offering binaries built with 8/16/32/64 bit limits in data types and max records per table, each being its own edition and priced accordingly? Eg yearly license of $8/160/3,200/640,000.

It's very creative! LOL But in practice most my tables that are uncapped end up with IDs are 64bits and i suspect not being the only one.. 32b is in fact quite small ~ 4B rows.

And so you would pay for the largest tier as it sounds like you have big data needs? ;P Whereas my company--which only had tens of millions of users and millions of dollars a year in revenue--certainly never had any tables with more than 4 billion rows... (not that I think this licensing model works or makes any sense at all, to be clear).

Reply on news.ycombinator.com