[seancolsen]

(Mathesar core team member here.) Thanks for the kind words! Our demo server actually spins up a unique database for each session, giving you the capability to make changes to the database and try Mathesar's features to the fullest extent. Your changes are only visible to you unless you send the link to someone else.

[debarshri]

Could you elaborate that a bit?

That sounds interesting too.

[kgodey]

Yes! We have set up a Postgres template database[1] with our demo data sets. When a user logs in, we create a new database based on the template database and associate the database with the session key set up for that login. So every session is associated with a different database and we have some Django middleware that routes you to the URL associated with your session's database. If you log out and log back in (thus ending your session), you'll be routed to a brand new database.

However, all databases are accessible to the demo user, so if you send a link to someone else, they will see your database (since the URL includes the database identifier).

You can see our code for it here: https://github.com/centerofci/mathesar/tree/develop/demo

[1] https://www.postgresql.org/docs/current/manage-ag-templatedb...

[xupybd]

How on earth are you handling HN front page traffic if you spin up a template copy per session? That is impressive.

[koolba]

You’d be (pleasantly) surprised how easy it is to copy a postgres database. It literally copies the data files for the database to a new directory so the operation is relatively quick if the total volume of data is not large.

What’s more challenging is handling many concurrent connections as a different database would mandate a separate connection and you can’t perform any meaningful connection pooling.

[dmos62]

That's accurate! Another bottleneck we have is Mathesar-level state management. We keep some state to reduce redundant Postgres queries. During most of development we focused on single-database use cases, but for the demo we had to expand to managing state for multiple databases in as isolated way as possible. That forced us to face some technical debt in assumptions we made about our state and how we organize it. State-related technical debt is the most challenging, imo.

[debarshri]

Thanks!