HN user

mble_

27 karma

https://matt.blwt.io/about

Posts0
Comments20
View on HN
No posts found.

PlanetScale | https://planetscale.com/ | Software Engineer - PlanetScale Postgres | Remote (AMER, LATAM & EMEA) | Base range: $120,000 - $290,000 USD

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.

Why not both?

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.

I just think we must have completely different working experiences.

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.

Author here.

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.

Pinot is something I haven't had any personal experience with, so that's why it wasn't on the list - same with StarRocks, or Druid.

Something for me to look into next year, clearly.

What people usually do for HA with PostgreSQL or do they just not care about it?

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...

Yeah, this is the bit for me. We have almost no good OSS layers for folks to "plug and play".

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.

Definitely doesn't replace databases, at least LLMs as they currently are. We're going to be stuck with relational algebra for a long time to come, but the interfaces to interact with store might change over time from SQL to more natural language.

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".

I didn't want ClickHouse to take all the glory. /s

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".

Author here.

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.

Author here. I deliberately didn't include one because I'm waiting for the dust to settle a bit.

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.

Hey, I wrote this! Thanks for all the additional warm feelings about Lua on its 30th birthday year.

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.

Hey, I wrote this! Happy to answer Qs about stuff I've learned for operating and being responsible for ETOOMANY Postgres, MySQL, Redis, Kafka, Cassandra and OpenSearch installs over the years.