Last week I wrote about why I wanted to build Console. This weekend I finally stopped thinking about it and built the first working prototype.

If you haven't read the previous note, you can read it here.

Previous Note

The idea behind Console is pretty simple.

It's just an admin panel for your existing database.

Not a spreadsheet pretending to be an admin panel, and not a CMS that wants to become the center of your application. Just an admin interface you can share with your clients or teammates without making them feel like they're operating pgAdmin.

Over the past few days I spent quite a bit of time looking at how existing tools solve this problem.

Payload stores everything inside your application's database. It owns the models, authentication, permissions, relationships, and basically becomes part of your architecture.

Then there are tools like Directus, which take a different approach. They keep their own metadata in a separate database while connecting to yours.

While researching I also came across Kottster. It's actually pretty close to what I'm building. You give it a database connection, it generates an admin interface from your schema, and it stores administrator accounts and permissions inside its own SQLite database.

That got me thinking.

Where should permissions live?

This ended up being the first architectural decision for Console.

There are a couple of options.

The first is storing everything inside the user's database. PostgreSQL already provides users, roles, row-level security, and plenty of permission features.

The problem is that Console would now have to create tables, manage migrations, keep its metadata in sync with the user's database, and generally become much more coupled to the application.

The second option is much simpler.

Console owns its own SQLite database.

Administrator accounts, permissions, sessions, and internal metadata all live there.

The user's database remains untouched.

Console only connects to inspect the schema and query the data.

For now, I think that's the right trade-off.

It keeps the architecture simple, removes external dependencies, and makes it much easier to get started.

The goal has always been the same.

I want the developer experience to feel like this.

bunx console start

Connect your database.

Create your admin.

Start managing your application.

That's it.

No giant configuration files.

No CMS to adopt.

No rewriting your application around another framework.

Just connect, manage your data, and move on with your life.

The prototype is still very early, but it already works.

Right now you can:

• Connect to a PostgreSQL database
• Browse schemas
• Inspect tables
• View rows
• Search records
• Sort data

Here's the current prototype.

Most of this was built in a single day. I was mainly experimenting with schema introspection and figuring out how to render a database as an actual admin interface instead of just another table viewer.

The tech stack is intentionally small.

• SvelteKit
• Bun
• SQLite

That's it.

The project is still in the "playing with ideas" phase, but having a working prototype feels much better than another folder full of notes.

We'll see where it goes from here.