A lot of terminal setups look productive… until you restart your machine

Oleh Klokov — Mon, 15 Dec 2025 15:00:00 +0000

If you regularly run multiple dev servers, keep SSH sessions open, tail logs, or bounce between projects, you know the routine:

reopen terminal windows,
reconnect to hosts,
recreate splits,
re-run commands,
repeat.

I didn’t want “cool terminal aesthetics”. I wanted a workspace that survives normal life.

So I built a simple, repeatable workflow on macOS:

Ghostty as the terminal UI layer (native macOS windows/tabs, clean config)
tmux as the state layer (sessions/windows/panes, detach/attach, persistence)
plus one decision that keeps the setup practical: tmux auto-starts only in Ghostty - Terminal.app stays clean.

The small controversy: tabs aren’t a workspace

This is the harmless terminal holy war:

“Why not just use terminal tabs?”

Because tabs are a view. They don’t encode recovery.
Your layout and runtime context still live in your head.

tmux is different:

It has a stable model: session → windows → panes
It supports detach/attach and long-running sessions
It’s keyboard-first and consistent across machines
It encourages repeatable structure: one session per project, windows per task

To be clear: tabs are great. I still use Ghostty tabs - but as a UI feature, not as my persistence strategy.

What I wanted from my setup

1) Persistence without friction

I want to reopen my terminal and continue:

same project context,
same commands running,
same layout.

2) Separation of concerns

A terminal emulator should not decide how I manage sessions.
And tmux should not hijack every shell I open.

So I made it explicit:

Ghostty = development workspace
Terminal.app = default system shell

3) Reproducibility

A “good setup” that can’t be recreated is just a lucky accident.

So I stored everything in a repo:

Ghostty config
tmux config (+ TPM plugins)
a zsh snippet to autostart tmux only in Ghostty
documentation and usage notes

What this gives me in practice

Instant “back to work”

Open Ghostty → attach to main → everything is already there.

A workflow that matches real development

one session per project,
windows for backend/logs/infra,
panes for quick splits.

Less mental overhead

Instead of thinking “where did I run that command?”, the structure stays consistent.

Easy migration

New machine? Clone repo, copy configs, install tmux, done.

What’s in the repository

config/ghostty/config - Ghostty config (fonts, keybindings, Option-as-Alt)
config/tmux/tmux.conf - tmux config (window/pane bindings, copy-mode, plugins)
config/zsh/tmux-ghostty.zsh - auto-start tmux only in Ghostty
a full README with installation steps and daily usage (sessions/windows/panes)

Repo: https://github.com/Gunpy/ghostty_tmux.git

Who should try this

This approach is especially useful if you:

run multiple dev servers and watchers daily,
keep SSH sessions open,
work across multiple environments,
want persistence without turning tmux into a global requirement.

If you’re a “no tmux, only tabs” person - that’s fair.
But if you’ve ever rebuilt the same terminal state three times in a week, tmux starts to look less like a hobby and more like ergonomics.

Closing

This setup is intentionally boring:

minimal moving parts,
predictable behavior,
and easy to reproduce.

If you try it, I’d love to hear how you organize your workspace:

one session per project,
one session for everything,
or separate sessions for local vs remote?

Repo: https://github.com/Gunpy/ghostty_tmux.git

Choosing a Database Isn’t About Hype - It’s About the Stage of Your Product

Oleh Klokov — Tue, 09 Dec 2025 17:37:42 +0000

Selecting a database is not about following hype or choosing what’s trending on tech Twitter.

It’s about understanding what stage your product is in, the shape of your data, and the load patterns your system actually handles.

Here’s a practical, engineer-focused breakdown of how to make the right choice.

MVP / Early Startup Stage

At this stage, your priorities are clear:

Launch fast
Avoid DevOps complexity
Keep costs low
Iterate on product, not infrastructure

Recommended options:

Supabase
Firebase
MongoDB Atlas (Free Tier)

Why these?

Because you don’t need multi-region replicas or an enterprise- grade SQL setup before you even have users.You need a database that helps you build features quickly with minimal overhead.

Production Stage

Once real users appear, the requirements change significantly:

Predictability
Transactional integrity
Schema stability
Query planning and indexing
Long-term data reliability

Best fits:

PostgreSQL
MySQL (managed)

Relational databases shine here because your data model stabilizes and you need strong guarantees on consistency, migrations, and analytics.
Supabase/Firebase can still work in production, but relational databases remain the safer long-term foundation.

AI-Driven Applications

AI workloads behave differently from traditional CRUD systems:

High RPS
Expensive operations
Short-lived intermediate data
Heavy caching needs
Semantic search requirements

A typical architecture becomes hybrid:

Redis + PostgreSQL
Redis + ClickHouse
Vector DB (Pinecone, Weaviate) + SQL

Roles:

Redis
- caching model responses
- rate limiting
- job processing queues
- fast temporary storage
SQL
- user history
- generated content
- logs
- analytics
Vector DB
- embeddings
- semantic search
- retrieval pipelines

Trying to push AI workloads into a single SQL database usually leads to bottlenecks.

Data-Centric Applications

This applies to CRMs, dashboards, admin panels, SaaS tools with heavy reporting, and anything where data relationships* are the core of the product.

You need:

consistency
clear relational structure
predictable JOIN performance
strict schema control

Use:

PostgreSQL
MySQL

If most of your product revolves around data tables, relational databases are the strongest choice.

Summary

MVP:

Supabase / Firebase / MongoDB → move fast.

Production:

PostgreSQL / MySQL → stay stable.

AI workloads:

Redis + SQL + Vector DB → maximize speed and flexibility.

Data-heavy applications:

Pure SQL → structure is your advantage.

Conclusion
Choosing a database is not about picking the flashiest tool or copying another team’s stack.

Early products don’t need enterprise-level infrastructure.
Mature systems can’t rely on flexible-but-loose NoSQL setups.
AI systems require a hybrid approach.
Data-focused apps thrive on relational clarity.

DEV Community: Oleh Klokov