Hacker News new | ask | show | jobs
by DasIch 1004 days ago
> Just like API's, databases have tools to allow you to evolve - for example, maintaining views that keep a contract while changing the underlying schema.

What are the database tools for access logs, metrics on throughput, latency, tracing etc.? Not to mention other topics like A/B tests, shadow traffic, authorization, input validation, maintaining invariants across multiple rows or even tables...

Databases often either have no tools for this or they are not quite as good.
2 comments
camgunz 1004 days ago
- Access logs: audit logging [0]

- Throughput/latency: pg_stat_statements [1] or Prometheus' exporter [2]

- A/B tests: aren't these frontend things? recording which version a user got is an INSERT

- Auth: row-level security [3] and session variables

- Tracing, shadow traffic: I don't think these are relevant in a "ship your database" setup.

- Valdation: check constraints [4] and triggers [5]

Maybe by some measures they're "not quite as good", but on the other hand you get them for free with PostgreSQL. I've lost count of how many bad internal versions of this stuff I've built.

[0]: https://severalnines.com/blog/postgresql-audit-logging-best-...

[1]: https://www.postgresql.org/docs/current/pgstatstatements.htm...

[2]: https://grafana.com/oss/prometheus/exporters/postgres-export...

[3]: https://www.postgresql.org/docs/15/ddl-rowsecurity.html

[4]: https://www.postgresql.org/docs/15/ddl-constraints.html

[5]: https://www.postgresql.org/docs/15/plpgsql-trigger.html

link
jyrkesh 1004 days ago
Honestly, there's plenty of tools out there that can do the same thing.

The important crux of the counterpoint to this article is "if you ship your database, it's now the API" and everything that comes along with that.

All the problems you _think_ you're sidestepping by not building an API, you're actually just compounding further down the line when you need to do things to do your database other than simply "adding columns to a table". :\

Edit: re-reading, the point I didn't make is that having your database be your API _is_ viable, so long as you actually treat it as an API instead of an internal data structure.

link