Connect your existing PostgreSQL database or let SolidX set one up. Each model can target its own datasource - mix databases freely, even within a single module. All powered by TypeORM and environment-driven configuration.

npx @solidxai/solidctl@latest create-app

View Setup Docs →

Datasources per app

Hardcoded credentials

DB engines supported

🔷

TypeORM Integration

Active ORM layer

.env · SolidX Config

✦ Connected

# ─── Application ───────────────────────

APP_PORT=3000

NODE_ENV=production

# ─── PostgreSQL Connection ──────────────

DB_HOST=db.solidx.internal

DB_PORT=5432

DB_NAME=school_fees_portal

DB_USER=solidx_admin

DB_PASSWORD=••••••••••••

# ─── TypeORM Options ────────────────────

DB_SYNCHRONIZE=false

DB_LOGGING=error

DB_SSL=true

PostgreSQL · Connected

db.solidx.internal:5432

PostgreSQL Primary

Optimised for PostgreSQL as the production-ready default database engine.

TypeORM Abstraction

All database interactions routed through TypeORM - clean, typed, and swappable.

Zero Hardcoded Creds

All connection details live in environment variables. Never baked into source code.

Per-Model Datasource

Each model can point to its own database. Mix datasources freely - even within a single module.

Centralized Configuration

One .env file controls your entire database setup.

SolidX accesses all database connection parameters - host, port, credentials, and SSL settings - exclusively through environment variables, wired into the NestJS ConfigModule. No credentials in source code. No per-developer config drift. No secrets in your git history.

NestJS ConfigModule - database settings are injected via ConfigService, not imported as static values, so every environment (dev, staging, prod) is independently configurable.

SSL-ready by default - enable encrypted connections to your PostgreSQL instance with a single DB_SSL=true flag. No code changes required.

Connection pooling controls - configure min/max pool size, idle timeout, and connection retries through environment variables to tune performance for your workload.

Read the configuration reference →

database.config.ts

NestJS ConfigModule

import { TypeOrmModuleOptions } from '@nestjs/typeorm';
import { ConfigService } from '@nestjs/config';

export const getDatabaseConfig = (
config: ConfigService,
): TypeOrmModuleOptions => ({

type: 'postgres' // abstraction layer,

host: config.get('DB_HOST'),

port: config.get<number>('DB_PORT'),

username: config.get('DB_USER'),

password: config.get('DB_PASSWORD'),

database: config.get('DB_NAME'),

  ssl: config.get('DB_SSL') === 'true',
  synchronize: false, // always use migrations
  autoLoadEntities: true,
  logging: config.get('DB_LOGGING'),
});

SolidX · Database Abstraction Stack

SolidX Application Layer

Modules, Models, Services, Controllers

NestJS

↕

TypeORM Abstraction

Entities · Repositories · Migrations

ORM Layer

↕

ConfigModule / Env Variables

DB_HOST · DB_PORT · DB_NAME · DB_USER

Config

↕

PostgreSQL Database

Metadata tables + Application data

Live

TypeORM Integration

Database abstraction that decouples your app from the engine.

SolidX uses TypeORM as the ORM layer between your application logic and the database. TypeORM's driver model means that swapping the underlying database engine - from PostgreSQL to MySQL, for example - requires only a configuration change, not a codebase rewrite.

Decorator-based entities - every SolidX model definition generates a @Entity()-decorated TypeORM class, making schema changes transparent and traceable.

Migration-safe - synchronize: false in production ensures schema changes only happen through versioned migrations, never automatically.

Repository pattern - all data access uses TypeORM repositories injected via NestJS DI, meaning your business logic never calls raw SQL directly.

Explore the TypeORM entity docs →

Dual-Purpose Storage

Your database, your rules.

By default, a single PostgreSQL database stores both SolidX's system metadata - module definitions, model schemas, field configurations, role structures - and your application data. But you're not limited to one database. Point SolidX at your existing databases, or configure additional datasources - each model can target a different database, even within the same module.

Bring your own database (coming soon) - connect SolidX to your existing PostgreSQL (or MSSQL) instance. No need to start from scratch - just point the environment variables at your current database and SolidX works with your data.

Per-model datasource - each model has its own dataSource property. Models within the same module can read and write to completely different databases. Mix PostgreSQL and MSSQL in a single application.

Metadata + app data co-located - SolidX stores module, model, and field definitions in system tables alongside your application data. A single pg_dump captures your entire application state, including its configuration.

Understand the SolidX schema layout →

🐘

school_fees_portal

PostgreSQL · All tables

Connected

⚙️ System Metadata

solidx_modulesmetadata

solidx_modelsmetadata

solidx_fieldsmetadata

solidx_rolesiam

solidx_usersiam

solidx_permissionsiam

📦 App Data · Per-Model DS

student_masterdefault

fee_scheduledefault

payment_recordsbilling_db

academic_yeardefault

parent_guardianlegacy_db

+ 12 more tables

Everything under the hood.

The full set of database abstraction capabilities SolidX provides out of the box, today.

PostgreSQL Support

Full support from day one - JSONB columns, array types, and UUID primary keys work out of the box.

PostgreSQL 14+JSONBUUID

Per-Model Datasource

Each model defines its own dataSource and dataSourceType. Models in the same module can point to entirely different databases.

Per-ModelMulti-DBFlexible

TypeORM ORM Layer

All data access goes through TypeORM - decorators, repositories, and query builders.

TypeORMEntitiesRepositories

Bring Your Own Database

Point SolidX at your existing PostgreSQL or MSSQL instance. No greenfield requirement - work with your current data.

Existing DBBYODComing Soon

Environment-Driven Config

Database credentials are never stored in code. The NestJS ConfigModule injects all details at runtime.

ConfigModule.envNo Secrets

SSL & Secure Connections

Enable encrypted connections with DB_SSL=true. Compatible with AWS RDS, Supabase, Railway, and Neon.

SSL/TLSRDSSupabase

Database Roadmap

Two engines live.
More on the way.

PostgreSQL and MSSQL are fully supported today. SolidX's vendor-agnostic architecture and TypeORM abstraction layer mean adding new engines is a driver swap - not a rewrite. Each model can independently target any configured datasource.

Live Now