I'm looking for a database (relational would be preferred, but NoSQL is also okay) which can be run without an admin user. I want to setup the database with an admin user, but then delete the admin user forever and run the database only with non-admin users. Is there anything like that for Postgres, MongoDB, MySQL, etc.?

EDIT: The goal is to make the database 100% safe from unrestricted deletions. The normal users should only be able to insert data, deletions and edits should never be possible, also not for the admin.

Thanks for the help!

  • The database will be created locally on a customer's computer, if there is a admin user the password could be scraped during the setup process, which wouldn't make the database 100% safe – Niklas May 28 '19 at 11:44
  • 1
    What would prevent them from removing your software and the database and starting over? – Tom V May 28 '19 at 14:16
  • It sounds like you are attempting to install software/data into an actively hostile environment.... There is nothing you can do if you can't control the hardware, all you can do is slow them down/make it difficult. Host the database in the cloud, grant client/user a login with sufficiently reduced permissions and call it a day. – Jonathan Fite May 29 '19 at 12:42
  • Take a look at my answer here on SQLite. If you're writing an app, only allow INSERTs - no updates or deletes (via code). But, if your client has control of the back end, then you are in trouble! – Vérace Jun 2 '19 at 13:32

The reason you have Superusers is to clean up the mess made by regular Users.

Trying to take these powers away from Superusers is like asking them to service your car and promptly throwing away all their spanners and wrenches.

You say that you don't want data deleted.

Simple solution.
Don't give people the permission to do delete data.

Argument: "But Table owners can do anything to that table"

True. So don't give Users table-owner-level accounts.

Argument: "Superusers can do anything"

True. So don't give Users superuser-level accounts.

Only you should have access to this, to fix other people's messes.

Review your security model. Determine who needs what level of access to what, then apply it. You may well get some "resistance" to start with, but stick to your convictions. You're heading in the right direction.

  • For the user it's clear, but what if somebody gets the admin password in any way and can change data this way? – Niklas May 29 '19 at 8:37
  • Again, that comes down to your Security model. Who /should/ have the Keys to the Castle? That's down to you giving them to the right people (i.e. nobody but you). Who /has/ the Keys to the Castle? Auditing is the backstop that catches anything you've missed. Strong passwords and password management software will help, but ultimately it comes down to keeping your own house in order. – Phill W. May 29 '19 at 15:10

You can do that in PostgreSQL by running


but that isn't a good idea, because eventually you are going to need a superuser for certain operations (e.g, upgrade to a later version).

It is better to restrict the superuser so that it cannot login. This can be done with the configuration file pg_hba.conf in PostgreSQL and requires shell access to the server to undo. This is just as safe as living without a superuser, and it will save you headaches later on.

Not the answer you're looking for? Browse other questions tagged or ask your own question.