Live data from Hacker News

Ask HN: Which is your go to Database to use in a project?

news.ycombinator.com

1–10 of 15 posts

Re: Ask HN: Which is your go to Database to use in a project?

#6
PostgreSQL with Hasura answer 200% of our needs.

Hasura exposes a GraphQL API and translates GraphQL queries to SQL queries (that's how it solves the N+1 resolver problem).

It handles authorization and permissions using the PostgreSQL user system.

It manages triggers and so much more. You can extend the functionalities with Webhooks and custom remote GraphQL schema.

In shorter terms: Everything we need and so much more.

Re: Ask HN: Which is your go to Database to use in a project?

#7
post #6

PostgreSQL with Hasura answer 200% of our needs. Hasura exposes a GraphQL API and translates GraphQL queries to SQL queries (that's how it solves the N+1 resolver problem). It handles authorization and permissions using the PostgreSQL user system. It manages triggers and so much more. You can extend the functionalities with Webhooks and custom remote GraphQL schema. In shorter terms: Everything we need and so much mo…

Can you tell a little about you use cases

Re: Ask HN: Which is your go to Database to use in a project?

#8
post #7
post #6

PostgreSQL with Hasura answer 200% of our needs. Hasura exposes a GraphQL API and translates GraphQL queries to SQL queries (that's how it solves the N+1 resolver problem). It handles authorization and permissions using the PostgreSQL user system. It manages triggers and so much more. You can extend the functionalities with Webhooks and custom remote GraphQL schema. In shorter terms: Everything we need and so much mo…

Can you tell a little about you use cases

Edited the message to include a short description of Hasura.

Re: Ask HN: Which is your go to Database to use in a project?

#10
SQL. Doesn’t really matter what form, but it’s just easy to work with. We tend to mainly operate MSSQL, but we’re not so in bed with T-SQL that its hard for us to operate the few MySQL and Postgres databases we have.

SQL is easy to build on and maintain. Systems operators know how to run it both locally, on rented iron and in the cloud, and developers know how to utilise it. At least around here.

It frankly does everything we need as well, from being a database to being a queue and so on, and while there are other ways to do much of that, we’re not Netflix. Having the perfect tech stack is more expensive for us than not having it, because it requires our staff to know more things, and you can buy a loooooot of hours in Azure for the price of an additional developer/operations engineer.

Post reply on HN