I'm the hiring manager for this position.

Come build the best Postgres product on the planet with super talented folks, very high autonomy, tier-zero databases for some of the biggest and fastest growing data sets.

Apply at https://job-boards.greenhouse.io/planetscale/jobs/4251150009.

Feel free to contact me on LinkedIn or Bluesky if you'd like to talk more about the role. Tell me why Postgres extensions are both great and terrible.

There are times when pushing the work down to the database layer is appropriate - databases are quite good at a lot of these operations - but if you need more nuanced approaches (e.g. ANOVA, ARIMA, other kinds of forecasting or analysis), leverage the appropriate tools.

Likely! I've generally worked in smaller orgs (including as part of a much larger org, as with my current employer) and there is less access to dedicated resources.

> Even when no BI team is dedicated, there's usually someone that's wearing that hat.

100%. Unfortunately, this has commonly be me from my personal experience.

> In that way, identifying it and raising concern can be 'my job' but when investigating it, it could be a team effort.

Totally agreed.

For some additional context, I've spent my working career on data systems so I likely feel a much stronger affinity to this type of self-serve analysis than your average bear.

One of the main things here is that you should know your data well enough to articulate the right request from BI. In my experience, BI often end up as pure order takers - if you ask the wrong question, you get a lovingly formatted but wrong answer.

The other thing is that this assumes you have a BI team at hand - smaller teams/orgs often don't! Perhaps I should make this a little more explicit.

My central thesis, also not made explicit, is that leaders should be appropriately curious _and_ leverage the tools they have to be able to do things like "hey, this looks weird, what's up?" and share the data and their methodology - that way it can be corrected/investigated etc.

Something for me to look into next year, clearly.

Patroni for most cases. At Heroku we have our own control plane to manage HA and fencing which works very reliably. I also like the approach the Cloud Native PG folks have taken with implementing it in the k8s API via the instance manager[1].

Other options like Stolon or repmgr are popular too. Patroni is, despite the Jepsen testing, used well without issues in the majority of circumstances. I wouldn't over think it.

[1]: https://cloudnative-pg.io/documentation/1.24/instance_manage...

For document databases, I'm more interested in things like PoloDB and SurrealDB.

But relicensed to the "CockroachDB Software License" as a form of BSL to prevent reselling.

Its a bit of a vicious circle - because there is low exposure, no one is building those layers. Because no one is building the layers, there is no exposure.

> what characteristics make for a best in class ai database

As I said before, I think the space is moving too fast on what is "best in class" - see all the vector indexing work that has happened in the last ~6 months or so. Big, centralised vector stores for some applications will have very different profiles to vector stores on the edge/on device, for example.

As mentioned, I'm a big fan of boring technology, so I'm going to happily wait we have a boring "winner".

The actual reason is that DuckDB's API and integration into other places (e.g. Evidence) and its use of extensions (like the aforementioned gsheets one) gives it priority for me.

Additionally, its being used in a bunch more places like pg_duckdb that make it more "worth it".

Thanks for sharing! My choices are pretty coloured by personal experience, and I didn't want to re-tread anything from the book (Redis/Valkey, Neo4j etc) other than Postgres - mostly due to Postgres changing _a lot_ over the years.

I had considered an OSS Dynamo-like (Cassandra, ScyllaDB, kinda), or a Calvin-like (FaunaDB), but went with FoundationDB instead because to me, that was much more interesting.

After a decade of running DBaaS at massive scale, I'm also pretty biased towards easy-to-run.

There is a lot of activity in the space, from things like TurboPuffer (proprietary), Postgres extensions like VectorChord and pgvector, to established players like Elastic getting in on the action. Not to mention things like Pinecone.

I have a "second part" in the works on this about implementing something a little more advanced in Lua, and some more exploration of Lua's warts.