4 ms·

The DB part can also get technical as performance comes into play. Most startups are probably not encountering this problem, but they could.

utmb748 2y ago
Was in startup which quit before hitting 1000 users in app at the same time, but performance was top priority so data layer stack was quiet big.
no_wizard 2y ago
This may explain some of the popularity resurgence of SQLite (including distributed SQLite) It makes Database Per Customer type apps really easy, and that is something alot of SaaS products could benefit from.
- frollogaston 2y ago
  Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.
  - mdaniel 1y ago
    It sounds like you're currently struggling against provisioning new database instances (or clusters) when the delineation is actually at the database within that instance Compare: psql --host=team1.example -d team1 # versus psql --host=the-db.example -d team1 Sometimes one can get away with schema level split, which can allow cross schema references in a read only setup, but carries coupling concerns psql --host=the-db.example -d my_db -U team1 "select * from team1.orders o inner join team2.products p ..." I don't mean to troubleshoot over HN comments, as the problem space is filled with nuance and trade-offs, but intended it as "for your consideration"
    - frollogaston 1y ago
      Thanks, but it's something else. When I say people shove their data into other teams' DBs, I really mean into other teams' schemas... and they don't even have direct SQL access to their data anymore, rather the teams set up some CRUD API which they have to painfully maintain. We aren't using Postgres but a more specialized DBMS. Everyone basically does the first thing in your example, sharing one cluster. The real issue is it's a big corp with red tape around stuff, people don't want responsibilities like compliance, and people are rightfully scared of keeping things performant on a fancy DBMS. Our team isn't scared, we did it, but it wasn't easy either.
      - frollogaston 1y ago
        To clarify, team A has some data in a DB, team B comes along asking to store their own data in there too, team A sets up CRUD API through which team B writes their stuff into team A's DB then gets it back.

utmb748 2y ago

Was in startup which quit before hitting 1000 users in app at the same time, but performance was top priority so data layer stack was quiet big.

no_wizard 2y ago

This may explain some of the popularity resurgence of SQLite (including distributed SQLite) It makes Database Per Customer type apps really easy, and that is something alot of SaaS products could benefit from.

frollogaston 2y ago
Yeah, I keep telling people at work that we need to figure out how to make it easier for teams to manage their own DBs. There are so many teams trying to shove their data into some other team's DB.
- mdaniel 1y ago
  It sounds like you're currently struggling against provisioning new database instances (or clusters) when the delineation is actually at the database within that instance Compare: psql --host=team1.example -d team1 # versus psql --host=the-db.example -d team1 Sometimes one can get away with schema level split, which can allow cross schema references in a read only setup, but carries coupling concerns psql --host=the-db.example -d my_db -U team1 "select * from team1.orders o inner join team2.products p ..." I don't mean to troubleshoot over HN comments, as the problem space is filled with nuance and trade-offs, but intended it as "for your consideration"
  - frollogaston 1y ago
    Thanks, but it's something else. When I say people shove their data into other teams' DBs, I really mean into other teams' schemas... and they don't even have direct SQL access to their data anymore, rather the teams set up some CRUD API which they have to painfully maintain. We aren't using Postgres but a more specialized DBMS. Everyone basically does the first thing in your example, sharing one cluster. The real issue is it's a big corp with red tape around stuff, people don't want responsibilities like compliance, and people are rightfully scared of keeping things performant on a fancy DBMS. Our team isn't scared, we did it, but it wasn't easy either.
    - frollogaston 1y ago
      To clarify, team A has some data in a DB, team B comes along asking to store their own data in there too, team A sets up CRUD API through which team B writes their stuff into team A's DB then gets it back.