SQLite in .NET with Turso & EF Core

Traditional                     SQLite
───────────                     ──────
.NET App                        .NET App
   │                               │
   ▼                               ▼
SQL Server                      SQLite
   │                               │
   ▼                               ▼
Database Server                 app.db

No server. No separate service. Just a database file.

---

Problems SQLite Solves

SQLite is not a smaller SQL Server - it's a different deployment model.

---

Architecture

Traditional                    SQLite
┌──────────────┐              ┌──────────────┐
│ ASP.NET Core │              │ ASP.NET Core │
└──────┬───────┘              └──────┬───────┘
       │                             │
       ▼                             ▼
┌──────────────┐              ┌──────────────┐
│  SQL Server  │              │    SQLite    │
└──────┬───────┘              └──────┬───────┘
       │                             │
       ▼                             ▼
   Database                       app.db

---

SQLite + EF Core

dotnet add package Microsoft.EntityFrameworkCore.Sqlite

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlite("Data Source=app.db"));

Same EF Core queries work - the app doesn't care that the DB is a file.

---

6 Practical Use Cases

1. Local Development

Developer Machine
.NET API → SQLite → app.db

No SQL Server install for every developer.

2. Automated Tests

Test → Create SQLite → Run → Delete

Isolated, fast, no shared server.

3. Desktop Applications

MyApp.exe
   └── app.db

WPF, WinForms, .NET MAUI, internal tools.

4. Offline Applications

Internet ✗
    │
┌───▼───────────┐
│ Local App     │
│   SQLite      │
│   local.db    │
└───────────────┘
        │ later sync
        ▼
  Server Database

Field apps, inspections, surveys.

5. Small Internal Tools

ASP.NET Core → SQLite

No admin, no connection pools, no dedicated server.

6. Local Cache / App Data

Application
   ├── Cached data
   ├── Settings
   ├── Search index
   └── Offline changes
         all in SQLite

Better than JSON once data becomes relational.

---

SQLite vs SQL Server

Decision guide

Need a database?
        │
   ┌────┴────┐
   │         │
Small/local  Centralized
/offline     enterprise
   │         │
   ▼         ▼
 SQLite   SQL Server

---

Where SQLite Starts to Hurt

User A ─┐
User B ─┤
User C ─┼──▶ SQLite   ← concurrent writes become the bottleneck
User D ─┤
User E ─┘

Also weak for:

• Server-side management features
• SQL Server–specific tooling
• Large centralized systems
• Complex operational requirements

---

Size ≠ Concurrency

Large local dataset + low write concurrency + single app  →  SQLite ✓
Small dataset + hundreds of users + heavy writes         →  SQLite ✗

---

SQLite → Turso

Local SQLite                Turso
────────────                ─────
Application                 .NET Application
     │                            │
     ▼                         Internet
  app.db                          │
                                  ▼
                               Turso
                                  │
                            SQLite / libSQL

Turso keeps the SQLite/libSQL model but adds a hosted, distributed layer.

Good fit for:

• Small cloud / serverless apps
• Edge applications
• Prototypes
• Globally distributed apps that still want simple DB infrastructure

SQLite (embedded)
        │
        ▼
Local application
        │
        ▼
Turso (hosted / distributed)

---

Takeaway

The real skill is knowing when your application needs a database server - and when it doesn't.