I built db-studio, a free, open-source database studio you can run with npx

Hüsam — Sun, 01 Nov 2026 18:00:07 +0000

I'm Hüsam, a software engineer in Istanbul and the solo developer behind db-studio. It's a free, open-source database studio you can run locally with one command.

npx db-studio

Every database. One studio.

Browse tables, edit records, run queries, and explore schema diagrams in the same app. There's also a desktop app if you prefer a dedicated window.

Start with your existing database

Run the command from your project directory. db-studio looks for a DATABASE_URL in your project's .env file or environment. If it doesn't find one, you can paste a connection URL on the Connect page.

Open the local address printed in the terminal. You don't need to create a hosted account.

Connections are saved locally, and the CLI and desktop app share the same list. Each browser tab keeps its own connection, so you can work with different databases side by side.

Edit data like a spreadsheet

The latest update adds these editing workflows:

Select a range of cells, copy it with headers, and paste cells from a spreadsheet.
Review unsaved edits, revert a single cell, or undo with Cmd/Ctrl+Z.
Choose explicitly between NULL, empty text, and a column's default value.
Copy a row as JSON or a SQL INSERT statement.
Duplicate a row from its menu.

Editing and schema capabilities depend on the engine. For example, ClickHouse tables are read-only in the grid, while explicit mutations remain available in the query editor. A saved connection can also open read-only when its engine supports it.

Work across nine database engines

db-studio supports PostgreSQL, MySQL, SQL Server, MongoDB, SQLite, Redis, DuckDB, Oracle, and ClickHouse.

You can also connect to MariaDB, CockroachDB, TiDB, Turso/libSQL, and Cloudflare D1 through their supported engines.

The interface follows the database's data model. MongoDB has collections, and Redis has key types. Available operations vary with the database.

Queries, schemas, and optional AI

The query editor has syntax highlighting and autocomplete. You can save queries and inspect results as a table or JSON. Import and export support CSV, Excel, and JSON.

For relational databases, schema diagrams help you see how tables connect. You can also browse related records through foreign keys.

AI assistance is optional and uses your own provider key. It can help write, explain, optimize, or fix queries.

Both screenshots show the real app running against a local demo database.

Try it and tell me what needs work

db-studio is free under Apache 2.0. I build and maintain the database adapters, API, interface, CLI, and desktop app. Contributions and bug reports are welcome.

Website and documentation · Source code

Which database would you try first, and what's one task you'd want db-studio to make easier?

GitHub Actions Tutorial

Hüsam — Fri, 11 Oct 2024 16:59:15 +0000

We're continuing our series on making our GitHub workflow better. We've already talked about the basic GitHub workflow. Now, let's look at GitHub Actions.

GitHub Actions might seem tricky and complicated at first, but they are actually very helpful. It lets you set up automatic tasks in your workflow, which makes your work easier and more organized.

You might be wondering:

What exactly is "GitHub Actions"?
Is it really important?
How do you use it?

Don't worry! We'll answer all these questions in this article. We'll explain what GitHub Actions is, its main parts, why it's useful, and how to get started with it.

What is GitHub Actions?

GitHub actions is a tool that allow you to build better software, not specify for a specific language or platform, it is a feature that allows you to automate your workflow, like automating the build, testing, and deployment of your code, by integrating it with your repositories, so you can use it with your repository.

GitHub Actions components:

You can configure GitHub Actions workflow to be triggered when an event occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner,or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

Workflows:
- A workflow is a set of automated tasks described in a YAML file. It is usually placed in the .github/workflows directory of the root of your repository. It describes one or more jobs that can be triggered by events like code pushes, pull requests. for example, you can have a workflow that runs tests after every pull request.
- yaml file: is a human-readable data serialization standard that can be used in conjunction with all programming languages and is often used to write configuration files.
- .github directory: is a special directory that GitHub uses to store configuration files for your repository. It is used to store GitHub Actions workflows, issue templates, and other configuration files.
Actions:
An action is a reusable unit of code that can be used in a workflow. It can be a single command or a script that can be run. Actions can be used to automate your workflow, like building, testing, and deploying your code.
Events:
An event is a specific activity in a repository that triggers a workflow run. Examples include pushing code, creating a pull request, or publishing a new release.
Runners:
A runner is a virtual machine that runs your workflows when they're triggered. You can configure your workflow to run on a specific runner, such as Ubuntu Linux, Microsoft Windows, or macOS.
Jobs and Steps:
A workflow is made up of one or more jobs, and each job consists of multiple steps. Each step is either a shell script that will be executed or an action that will be run. For example, you can have a step that builds your application followed by a step that runs tests.
Secrets:
Secrets are encrypted environment variables that you can use in your workflows. You can use secrets to store sensitive information, such as API keys, passwords, and tokens. For example, if you want to use a VERCEL_TOKEN to deploy your application to Vercel, you can store this token as a secret in your repository and use it in your workflow.

Let's create a simple GitHub Actions workflow together:

Our task is to create a simple GitHub Actions workflow that runs Eslint on our
code whenever we push code to our repository. Here's how we can do it:

In your repository on GitHub, create a workflow file in the .github/workflows directory. You can name the file anything you want, but it should have a .yml extension. For example, you can name it main.yml.

Add the following code to the main.yml file:

name: Eslint check # name of the workflow
on: [push] # the event that triggers the workflow
jobs: 
  eslint: # name of the job
    runs-on: ubuntu-latest # the runner that the job will run on
    steps: 
      - name: start the job # name of the step
        run: echo "🚀 Start the job" # the command to run

      - name: Checkout code from repository
        uses: actions/checkout@v3 # an action to check out the code

      - name: Install dependencies
        run: npm ci # ci is used to install the dependencies faster than npm install

      - name: Run Eslint
        run: npx eslint .

Commit and push the changes to your repository.
View your workflow results:
1. In your repository on GitHub, click on the Actions tab.
2. You should see your workflow running or completed.

That's it! You've created your first GitHub Actions workflow. Now, whenever you push code to your repository, Eslint will run on your code.

Let's create a more complex one

Our second task is to create a workflow that runs Eslint and Prettier checks and build the application on every push or pull request to the main branch.

name: Eslint, Prettier, and Build

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  eslint:
    name: Eslint checks
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run Eslint
        run: npx eslint .

  prettier:
    name: Prettier checks
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run Prettier
        run: npx prettier --check .

  build:
    name: Build the application
    runs-on: ubuntu-latest

    needs: # this is used to specify that this job depends on the previous jobs
      - eslint
      - prettier

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Build the application
        run: npm run build

Let's create our third workflow, the most complex one

Our second task is to create a workflow that runs Eslint and Prettier checks on our code and run typescript checks and build the application and run tests on every pull request to the main branch.

name: Eslint, Prettier, Typescript, Build, and Test

on:
  pull_request:
    branches:
      - master

jobs:
  eslint-prettier:
    name: Eslint and Prettier checks
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run Eslint
        run: npx eslint .

      - name: Run Prettier
        run: npx prettier --check .

  typescript:
    name: Typescript checks
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run Typescript checks
        run: npx tsc --noEmit

  build:
    name: Build the application
    runs-on: ubuntu-latest

    needs:
      - eslint-prettier
      - typescript

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Build the application
        run: npm run build

  test:
    name: Run tests
    runs-on: ubuntu-latest

    needs: build

    steps:
      - name: Checkout code from repository
        uses: actions/checkout@v3

      - name: setup node environment
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test

here is how the workflow works:

Wraping up:

GitHub Actions is a powerful tool that helps you automate your workflow and make your work easier and more organized. It lets you set up automatic tasks, like building, testing, and deploying your code. You can use it to automate repetitive tasks and save time.

In this article, we've explained what GitHub Actions is, its main parts, why it's useful, and how to get started with it. We've also created two simple GitHub Actions workflows together. We hope this article has helped you get a better understanding of GitHub Actions and how you can use it to improve your workflow.

Resourses:

Articles:

Videos:

DEV Community: Hüsam