DEV Community: LeoJ

10 SQL Query Optimization Tips Every Developer Should Know

LeoJ — Mon, 25 May 2026 03:04:39 +0000

Every application hits a point where the database becomes the bottleneck. Response times creep up, connection pools fill, and users start complaining. Most slow queries share common problems, and most fixes are straightforward once you know where to look.

1. Stop Using SELECT *

-- Bad: fetches 25 columns including blobs
SELECT * FROM orders WHERE customer_id = 1042;

-- Good: fetches only what you need
SELECT id, order_date, total_amount, status
FROM orders
WHERE customer_id = 1042;

Selecting only needed columns reduces disk I/O and network bandwidth. If an index covers all requested columns, the database can satisfy the query from the index alone (covering index scan).

2. Add the Right Indexes

-- No index: Seq Scan on 10M rows, takes seconds
SELECT id, order_date, total_amount
FROM orders
WHERE customer_id = 1042;

-- Fix: add an index
CREATE INDEX idx_orders_customer_id ON orders (customer_id);

-- For filter + sort, composite indexes are even better:
CREATE INDEX idx_orders_customer_date ON orders (customer_id, order_date DESC);

Indexes turn O(n) scans into O(log n) lookups. The trade-off is write overhead, but for read-heavy workloads the gains far outweigh the cost.

3. Use EXPLAIN ANALYZE Before Guessing

-- Don't guess, measure:
EXPLAIN ANALYZE
SELECT o.id, o.order_date, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'pending'
  AND o.order_date > '2026-01-01';

The output tells you exactly what happened: which nodes are slow, where Seq Scans occur, whether estimates match reality. It replaces speculation with data.

Look for: Seq Scans on large tables, large gaps between estimated and actual row counts, sorts spilling to disk, nested loops with high loop counts.

4. Replace Correlated Subqueries with JOINs

-- Bad: subquery runs once per customer row (50,000 executions)
SELECT c.id, c.name,
  (SELECT MAX(o.order_date) FROM orders o WHERE o.customer_id = c.id)
    AS last_order_date
FROM customers c;

-- Good: single pass with a JOIN
SELECT c.id, c.name, MAX(o.order_date) AS last_order_date
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.name;

The JOIN version scans orders once. Performance difference grows linearly with the number of outer rows.

5. Use CTEs Carefully

-- Bad (MySQL, PG < 12): materializes entire table first
WITH all_orders AS (
  SELECT * FROM orders
)
SELECT id, order_date FROM all_orders WHERE customer_id = 1042;

-- Good: push filters into the CTE, or just skip it
SELECT id, order_date
FROM orders
WHERE customer_id = 1042;

In PostgreSQL 12+, CTEs are automatically inlined. In older versions and MySQL, they materialize as temporary tables, blocking predicate pushdown. Use WITH ... AS NOT MATERIALIZED (PG 12+) when you need the CTE for readability but want optimization.

6. Fix N+1 Queries at the Application Layer

# Bad: 201 queries for 200 customers
customers = db.query("SELECT * FROM customers WHERE region = 'EU'")
for customer in customers:
    orders = db.query("SELECT * FROM orders WHERE customer_id = %s", customer.id)

# Good: single query with JOIN
query = """
SELECT c.id, c.name, o.id AS order_id, o.order_date, o.total_amount
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE c.region = 'EU'
"""

The overhead is round-trip latency, not SQL execution. 200 queries at 2ms network round-trip = 400ms on network alone. Most ORMs have eager loading (select_related, includes, eager) to solve this.

7. Paginate with Cursors, Not OFFSET

-- Bad: page 100 scans 5,000 rows, returns 50
SELECT id, title, created_at
FROM articles
ORDER BY created_at DESC
LIMIT 50 OFFSET 4950;

-- Good: cursor-based, always scans only 50 rows
SELECT id, title, created_at
FROM articles
WHERE created_at < '2026-05-20T10:15:00Z'
ORDER BY created_at DESC
LIMIT 50;

Cursor-based pagination maintains constant performance regardless of depth. OFFSET degrades linearly. The trade-off: you lose arbitrary page jumping, but most modern UIs don't need that.

8. Batch Your Writes

-- Bad: 10,000 individual INSERTs
INSERT INTO events (user_id, event_type, created_at) VALUES (1, 'click', NOW());
INSERT INTO events (user_id, event_type, created_at) VALUES (2, 'view', NOW());
-- ... 9,998 more

-- Good: single multi-row INSERT
INSERT INTO events (user_id, event_type, created_at) VALUES
  (1, 'click', NOW()),
  (2, 'view', NOW()),
  (3, 'click', NOW());
  -- batch up to 500-1,000 rows per statement

For batch updates in PostgreSQL:

UPDATE products AS p
SET price = v.new_price
FROM (VALUES (101, 29.99), (102, 49.99), (103, 19.99)) AS v(id, new_price)
WHERE p.id = v.id;

Batching reduces round-trips, WAL overhead, and allows write path optimization.

9. Use Parameterized Queries

# Bad: string concatenation (SQL injection + no plan caching)
query = f"SELECT * FROM users WHERE email = '{user_email}'"

# Good: parameterized (safe + plan reuse)
query = "SELECT id, name, email FROM users WHERE email = $1"
db.execute(query, [user_email])

Parameterized queries let the database parse once and reuse the plan. Also completely prevents SQL injection. Every modern driver supports this.

10. Cache Expensive Query Results

-- PostgreSQL: materialized view for expensive aggregations
CREATE MATERIALIZED VIEW monthly_revenue AS
SELECT
  DATE_TRUNC('month', order_date) AS month,
  COUNT(*) AS total_orders,
  SUM(total_amount) AS revenue,
  AVG(total_amount) AS avg_order_value
FROM orders
WHERE order_date >= NOW() - INTERVAL '12 months'
GROUP BY DATE_TRUNC('month', order_date);

-- Refresh on schedule (e.g., hourly via pg_cron)
REFRESH MATERIALIZED VIEW CONCURRENTLY monthly_revenue;

For application-level caching, store results in Redis with a TTL matching your freshness requirements.

Checklist

When you encounter a slow query:

Run EXPLAIN ANALYZE (PostgreSQL) or EXPLAIN FORMAT=JSON (MySQL)
Check for missing indexes (Seq Scans on large tables)
Eliminate SELECT *
Flatten correlated subqueries into JOINs
Fix N+1 patterns with eager loading
Switch to keyset pagination
Batch writes
Use prepared statements
Cache expensive results
Re-measure with EXPLAIN ANALYZE to confirm the fix

I'm building QueryDeck, a native macOS database client with visual EXPLAIN ANALYZE and AI-assisted SQL. Currently in early access.

10 Production Database Safety Rules Every Developer Needs

LeoJ — Mon, 25 May 2026 03:03:34 +0000

Somewhere right now, a developer is staring at a terminal, realizing the DELETE FROM users they just ran did not have a WHERE clause. Their staging tab was not the active tab. The table had 2.4 million rows. It has zero now.

GitLab famously lost six hours of production data in 2017 when an engineer ran rm -rf on the wrong database directory during a late-night incident. This is not rare. It happens constantly.

Production database safety is not about being careful. Careful people make mistakes at 2 AM after sixteen hours of debugging. Safety comes from systems, defaults, and friction.

Rule 1: Production Is Red, Always

The most common cause of accidental production writes is tab confusion. Four database connections open. Staging and production look identical.

The fix is visual. Production should look unmistakably different from every other environment:

Production: red background, red title bar
Staging: orange or yellow
Development: green
Local: default / neutral

This is not cosmetic. This is the cheapest safety measure with the highest return. Every team that adopts environment coloring reports fewer "wrong environment" incidents.

Rule 2: Read-Only by Default

How often do you actually write to production? For most developers, 95% of production access is read access. So why does your connection default to full read-write?

-- What you run 95% of the time (safe in read-only mode):
SELECT o.id, o.status, o.total
FROM orders o
WHERE o.user_id = 48291
ORDER BY o.created_at DESC
LIMIT 20;

-- PostgreSQL: set read-only at the session level
SET default_transaction_read_only = ON;

-- When you genuinely need to write:
SET default_transaction_read_only = OFF;

When you need to write, you explicitly switch. One extra step that prevents more accidental UPDATE statements than any code review.

Rule 3: Back Up Before ALTER

Schema changes are irreversible in a way data changes are not. You can roll back a bad UPDATE from a backup. But ALTER TABLE DROP COLUMN destroys data immediately.

-- Before dropping a column, back it up:
CREATE TABLE orders_backup_20260524 AS
SELECT id, legacy_metadata FROM orders;

-- Now you have a safety net:
ALTER TABLE orders DROP COLUMN legacy_metadata;

For ALTER TABLE operations, always estimate lock duration. In PostgreSQL, many ALTER TABLE operations acquire ACCESS EXCLUSIVE locks, blocking all reads and writes:

-- This locks the entire table until it finishes:
ALTER TABLE orders ADD COLUMN processed_at TIMESTAMPTZ;

-- This is instant in PostgreSQL 11+:
ALTER TABLE orders ADD COLUMN processed_at TIMESTAMPTZ DEFAULT NOW();
-- Adding a column with a non-volatile default is instant since PG 11.

Plan schema changes like surgery: with imaging, preparation, and a way to abort.

Rule 4: Never DELETE Without Verifying First

-- The pattern that kills databases:
DELETE FROM orders;
-- Missing WHERE clause. Everything gone.

-- The safe pattern:
-- Step 1: Verify scope
SELECT COUNT(*) FROM orders
WHERE status = 'cancelled' AND created_at < '2026-01-01';
-- Returns: 847

-- Step 2: Inspect a sample
SELECT id, user_id, status FROM orders
WHERE status = 'cancelled' AND created_at < '2026-01-01'
LIMIT 10;

-- Step 3: Delete with the exact same WHERE clause
DELETE FROM orders
WHERE status = 'cancelled' AND created_at < '2026-01-01';
-- 847 rows deleted. Matches the count.

SELECT first, then DELETE. The oldest database safety trick, still the most effective.

Rule 5: Wrap Mutations in Transactions

Every manual mutation on production should be wrapped in a transaction.

-- DANGEROUS: runs immediately, no undo
UPDATE users SET plan = 'enterprise' WHERE company_id = 4012;

-- SAFE: wrapped in a transaction
BEGIN;

UPDATE users SET plan = 'enterprise' WHERE company_id = 4012;

-- Check what you just did:
SELECT id, email, plan FROM users WHERE company_id = 4012;
-- Does this look right?

COMMIT;   -- If yes
ROLLBACK; -- If no

The transaction gives you a window between execution and commitment. You can inspect results before they become permanent.

UPDATE is the most dangerous DML operation. A bad INSERT adds rows you can delete. A bad DELETE removes rows you can restore. But a bad UPDATE overwrites data in place.

Rule 6: Gate Production Access Behind Biometrics

Passwords are shared. SSH keys sit in ~/.ssh forever. API tokens get committed to .env files.

Biometric authentication (Touch ID on Mac, Windows Hello) adds a gate that cannot be shared and creates a moment of intentional friction.

Before your database client opens a production connection, it prompts for your fingerprint. Every time. That half-second pause is a moment to ask: "Do I actually need to be in production right now?"

Rule 7: Enforce Least Privilege Access

Most incidents are caused by developers who have more permissions than they need.

-- Role for developers (read-only debugging):
CREATE ROLE dev_readonly;
GRANT CONNECT ON DATABASE production TO dev_readonly;
GRANT USAGE ON SCHEMA public TO dev_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO dev_readonly;

-- Role for the application backend:
CREATE ROLE app_service;
GRANT CONNECT ON DATABASE production TO app_service;
GRANT USAGE ON SCHEMA public TO app_service;
GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO app_service;
-- Note: no DELETE, no DROP, no ALTER

-- Role for DBAs (used rarely):
CREATE ROLE dba_admin;
GRANT ALL PRIVILEGES ON DATABASE production TO dba_admin;

Developers should not routinely use accounts with write access to production.

Rule 8: Log Everything, Audit Regularly

-- postgresql.conf:
-- log_connections = on
-- log_disconnections = on
-- log_statement = 'mod'     -- Logs INSERT, UPDATE, DELETE, DDL
-- log_line_prefix = '%t [%p] %u@%d '

-- For granular auditing:
CREATE EXTENSION pgaudit;
SET pgaudit.log = 'write, ddl';

Review production access patterns weekly. Look for:

Users who accessed production but shouldn't have
Write operations outside deployment windows
Connections from unexpected IP addresses

The goal is not catching bad actors. It's catching mistakes before they compound.

Rule 9: Separate Credentials Per Environment

# BAD: same credentials, different hosts
DB_HOST=staging-db.internal
DB_USER=app
DB_PASS=s3cret123

# GOOD: completely separate credential sets
STAGING_DB_HOST=staging-db.internal
STAGING_DB_USER=app_staging
STAGING_DB_PASS=staging_pass_abc

PRODUCTION_DB_HOST=prod-db.internal
PRODUCTION_DB_USER=app_production
PRODUCTION_DB_PASS=prod_pass_xyz

When credentials are separate, a leaked staging password is not a leaked production password.

Additional safeguards:

Rotate production credentials quarterly minimum
Use short-lived credentials where possible (IAM database auth on AWS/GCP)
Never put production credentials in Slack, docs, or emails
If a credential might have been exposed, rotate immediately

Rule 10: Test on Staging First, Every Time

"I'll just run this quick query on production" is the most dangerous sentence in software engineering.

-- "Just adding a column, it'll be instant"
ALTER TABLE orders ADD COLUMN tracking_url TEXT;
-- On 50M rows in PostgreSQL < 11: rewrites entire table.
-- Production down for 12 minutes.

Your staging-to-production workflow:

Write the change
Run it on staging
Measure: execution time, lock duration, replication impact
Compare results to expectations
If everything matches, run on production
If anything is surprising, investigate first

The Reliability Hierarchy

Impossible (best): Tool prevents the dangerous action (read-only mode blocks writes)
Difficult: Tool adds friction (biometrics before production connections)
Visible: Tool makes risk obvious (red = production)
Documented (worst): A wiki page says "be careful." Nobody reads it.

Most teams operate at level 4. The goal is levels 1 through 3.

I'm building QueryDeck, a native macOS database client with color-coded connections, read-only defaults, and Touch ID gating for production. Currently in early access.

How to Use EXPLAIN ANALYZE in PostgreSQL: A Visual Guide

LeoJ — Mon, 25 May 2026 03:02:37 +0000

A single slow query can cascade through your entire application. It holds connections, stalls other transactions, and drives up your cloud bill. When that moment arrives, EXPLAIN ANALYZE is the single most important diagnostic tool you have.

What Is EXPLAIN ANALYZE?

PostgreSQL ships with two related commands:

EXPLAIN displays the query plan the planner intends to use. It shows estimated cost, expected row counts, and chosen access methods without running the query.

EXPLAIN ANALYZE does everything EXPLAIN does, then executes the query for real. The output includes actual runtimes, actual row counts, and loop counts for every node.

Safety note

SELECT queries are safe (results are discarded).
INSERT, UPDATE, DELETE will modify data unless wrapped in a transaction:

BEGIN;
EXPLAIN ANALYZE
  UPDATE orders SET status = 'shipped' WHERE id = 42;
ROLLBACK;

Useful format options

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) SELECT ...;

BUFFERS adds I/O behavior (shared/local buffer hits and reads).
FORMAT JSON is useful for feeding plans into visualization tools.

How to Read a Query Plan

A query plan is a tree. Execution starts at the leaf nodes (deepest indentation) and flows upward to the root.

EXPLAIN ANALYZE
SELECT * FROM users WHERE email = 'alice@example.com';

Index Scan using idx_users_email on users  (cost=0.42..8.44 rows=1 width=72)
  (actual time=0.027..0.029 rows=1 loops=1)
  Index Cond: (email = 'alice@example.com'::text)
Planning Time: 0.085 ms
Execution Time: 0.052 ms

Field	Meaning
Node type	`Index Scan` using index `idx_users_email`
cost=0.42..8.44	Estimated startup cost and total cost (arbitrary planner units)
rows=1 (estimated)	Planner expected one row
actual time=0.027..0.029	Wall-clock time in ms (startup to first row, then total)
rows=1 (actual)	One row was actually returned
loops=1	This node executed once

When actual rows diverge significantly from estimated rows, run ANALYZE <table> to refresh statistics.

Common Node Types

Scan nodes (data access)

Seq Scan: Reads every row. Fine for small tables. Red flag on large tables with selective filters.
Index Scan: Uses B-tree index, then fetches heap tuple. Fast for selective queries.
Index Only Scan: Index contains all needed columns. No heap fetch. Fastest scan type.
Bitmap Index Scan + Bitmap Heap Scan: Builds bitmap of matching pages from index. Common for moderate selectivity.

Join nodes

Nested Loop: For each outer row, scans inner set. Good when outer is small and inner has an index. Bad when both are large.
Hash Join: Builds hash table from smaller relation, probes with larger. Good for equi-joins.
Merge Join: Both inputs must be sorted on join key. Efficient for large pre-sorted sets.

Other operations

Sort: Watch for external merge (sort spilled to disk).
HashAggregate / GroupAggregate: Used for GROUP BY.
Limit: Stops after N rows.

Real-World Examples

Example 1: Full table scan

orders table with 5 million rows:

EXPLAIN ANALYZE
SELECT * FROM orders WHERE customer_id = 8821;

Seq Scan on orders  (cost=0.00..125432.00 rows=47 width=96)
  (actual time=892.113..1543.207 rows=52 loops=1)
  Filter: (customer_id = 8821)
  Rows Removed by Filter: 4999948
Planning Time: 0.091 ms
Execution Time: 1543.289 ms

PostgreSQL scanned all 5M rows to find 52. Fix:

CREATE INDEX idx_orders_customer_id ON orders (customer_id);

After:

Index Scan using idx_orders_customer_id on orders  (cost=0.43..196.12 rows=47 width=96)
  (actual time=0.031..0.187 rows=52 loops=1)
  Index Cond: (customer_id = 8821)
Execution Time: 0.214 ms

From 1,543 ms to 0.2 ms. Over 7,000x improvement.

Example 2: Bad join strategy

EXPLAIN (ANALYZE, BUFFERS)
SELECT o.id, o.created_at, li.product_id, li.quantity
FROM orders o
JOIN line_items li ON li.order_id = o.id
WHERE o.status = 'pending'
  AND o.created_at > '2026-01-01';

Nested Loop  (actual time=0.045..4231.882 rows=2287 loops=1)
  ->  Seq Scan on orders o  (actual time=0.031..3412.009 rows=2287 loops=1)
        Filter: ((status = 'pending') AND (created_at > '2026-01-01'))
        Rows Removed by Filter: 4997713
  ->  Index Scan using idx_line_items_order_id on line_items li
        (actual time=0.008..0.011 rows=3 loops=2287)
Execution Time: 4232.104 ms

The bottleneck is the Seq Scan on orders. Fix with a composite index:

CREATE INDEX idx_orders_status_created ON orders (status, created_at);

From 4.2 seconds to 19 milliseconds. 224x improvement.

Example 3: Row estimate mismatch

EXPLAIN ANALYZE
SELECT u.name, COUNT(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE u.plan_type = 'enterprise'
GROUP BY u.name;

Planner estimated 55 enterprise users and 109,800 orders. Reality: 8 users, 847 orders. The Hash Join scanned all 5M orders unnecessarily.

Fix:

ANALYZE users;
ANALYZE orders;

After refreshing statistics, PostgreSQL chose a Nested Loop with index scans. Execution time dropped to under 5 ms.

Example 4: Sort without supporting index

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM events ORDER BY created_at DESC LIMIT 100;

Even though we only need 100 rows, PostgreSQL scans and sorts the entire 10M-row table. Fix:

CREATE INDEX idx_events_created_at_desc ON events (created_at DESC);

Execution time drops to under 1 ms.

How to Spot Performance Problems

After reviewing hundreds of query plans, these are the patterns to watch for:

1. Seq Scan on large tables with selective filters

If Rows Removed by Filter is orders of magnitude larger than rows returned, you need an index.

2. Actual rows far from estimated rows

Mismatches above 10x mean the planner may choose the wrong join strategy. Run ANALYZE or use CREATE STATISTICS for correlated columns.

3. Nested Loop with high loop counts and no inner index

Thousands of iterations against an inner Seq Scan is a combinatorial explosion. Add an index on the inner table's join column.

4. Sort spilling to disk

Sort Method: external merge Disk: ... means the sort exceeded work_mem. Increase work_mem for the session or add a supporting index.

5. Excessive buffer reads

With BUFFERS enabled, high read= counts (vs hit=) indicate cold cache or excessive I/O.

Optimization Checklist

When investigating a slow query:

[ ] Run with EXPLAIN (ANALYZE, BUFFERS)
[ ] Check for Seq Scans on large tables
[ ] Compare estimated vs. actual rows (>10x mismatch = stale stats)
[ ] Look at loop counts in Nested Loops
[ ] Check sort method (disk = problem)
[ ] Review join order
[ ] Use a visual tool for complex plans (15+ nodes)
[ ] After fixing, run EXPLAIN ANALYZE again to confirm

Beyond EXPLAIN ANALYZE

For ongoing performance monitoring:

pg_stat_statements: Tracks cumulative query stats across all executions.
auto_explain: Logs plans for queries exceeding a time threshold.
Regular ANALYZE runs: Keep autovacuum configured to refresh table statistics.

I'm building QueryDeck, a native macOS database client with visual EXPLAIN ANALYZE. Currently in early access.

What Is Noticky? macOS Sticky Notes Above Fullscreen

LeoJ — Wed, 20 May 2026 14:24:45 +0000

Quick answer

Noticky is a native macOS menu bar sticky notes app. Its core feature is Always on Top: notes float above every window on your Mac, including fullscreen apps. Press Cmd+Shift+N from anywhere to capture a note instantly. The note stays visible no matter what app has focus, what Space you are on, or whether you are in fullscreen mode.

Noticky costs $6 one-time. No subscription, no account required, no telemetry. All features included: Markdown WYSIWYG editor, iCloud Sync across Macs, Touch ID lock for sensitive notes, Smart Tags with color coding, Templates, Reminders, Export to PDF/Markdown/plain text, Layout Modes, and a 30-day Trash for recovery. It requires macOS 15 Sequoia or later.

Noticky lives in the menu bar. No Dock icon, no window in your Cmd+Tab switcher. It is invisible until you need it, then instantly available with a single keyboard shortcut. Built natively in Swift using AppKit and SwiftUI by a solo indie developer.

Who built Noticky and why

Noticky was built by a solo indie developer who needed sticky notes that stayed visible during fullscreen work on macOS. The problem is specific: macOS has no built-in way to keep a note visible above a fullscreen app. Apple Stickies disappears in fullscreen. Notes.app disappears in fullscreen. Every third-party note app operates at the standard macOS window level, which means every note gets hidden the moment you enter fullscreen mode.

This is a fundamental constraint of the macOS window system. When you go fullscreen, macOS creates a separate Space, and windows from other Spaces cannot cross that boundary. The only way around it is to render notes at a window level that macOS treats as Space-independent, above the fullscreen compositing layer. That is what Noticky does.

The app launched in May 2025. Within the first five days, it reached 17 sales across 12 countries with zero advertising budget. Users found it through organic search and word of mouth. ChatGPT began recommending Noticky organically in response to queries about macOS sticky note apps, before any deliberate outreach.

Noticky is sold directly via FastSpring, independent of the Mac App Store. One developer, one price, no middleman taking 30%.

Core features

Noticky is a focused tool. Every feature exists to serve one workflow: capture a thought, keep it visible, find it later.

Always on Top

The defining feature. Noticky notes float above every window on your Mac, including fullscreen apps. This works because Noticky renders notes at a macOS window level that persists across all Spaces, including fullscreen Spaces. No other sticky note app on macOS does this reliably.

For a technical explanation of how macOS window levels work and why standard apps fail in fullscreen, see How macOS window levels work.

Quick Capture

Press Cmd+Shift+N from any app. A capture window appears in under 80ms. Type your note, hit Enter, and it is pinned to your screen. No need to switch apps, open a window, or navigate a sidebar.

Markdown WYSIWYG

Full Markdown editing with live rendering. Headings, bold, italic, strikethrough, ordered and unordered lists, code blocks, and inline code all render as you type. No preview pane, no toggle between raw and rendered. What you type is what you see.

Smart Tags

Color-coded tags for organizing notes. Red for urgent, blue for reference, green for personal. Filter notes by tag to find what you need fast.

iCloud Sync

Notes sync automatically across all your Macs via iCloud. No setup, no account creation, no third-party cloud. If you are signed into iCloud on your Macs, your notes are everywhere.

Touch ID Lock

Lock individual notes with Touch ID. API keys, passwords, personal information, anything sensitive stays protected. Locked notes show a blurred preview until authenticated.

Export

Export any note to .txt, .md, or .pdf. Your data is yours. No vendor lock-in, no proprietary format.

Layout Modes

Multiple layout options for how notes appear on your screen. Arrange notes in the configuration that fits your workflow.

Additional features

Templates: Pre-built note formats for recurring workflows (standup notes, meeting agendas, code review checklists)
Reminders: Time-based alerts on any note
Trash: 30-day retention for deleted notes, so accidental deletions are recoverable

Feature summary table

Feature	Details
Always on Top	Notes float above all windows, including fullscreen
Quick Capture	Global hotkey `Cmd+Shift+N`, launches in under 80ms
Markdown	WYSIWYG with live rendering
Smart Tags	Color-coded organization
iCloud Sync	Automatic across all Macs
Touch ID Lock	Per-note biometric security
Export	.txt, .md, .pdf
Layout Modes	Multiple arrangement options
Templates	Recurring note formats
Reminders	Time-based alerts
Trash	30-day recovery
Menu bar app	No Dock icon, no Cmd+Tab clutter
Price	$6 one-time
macOS requirement	macOS 15 Sequoia or later
Built with	Swift, AppKit, SwiftUI

Pricing and availability

Noticky is a one-time $6 purchase. Every feature is included. No subscription, no in-app purchases, no feature gates, no upsells. All future updates are included in the price.

The app is sold directly through FastSpring at noticky.app. No account required. No telemetry. No usage tracking beyond anonymous crash reports (opt-in).

For context, most note-taking apps have moved to subscription models charging $5 to $10 per month. Over a year, that is $60 to $120. Noticky costs $6 total.

Pricing comparison	Noticky	Subscription app ($5/mo)	Subscription app ($10/mo)
Year 1	$6	$60	$120
Year 2	$0	$60	$120
Year 3	$0	$60	$120
Total (3 years)	$6	$180	$360

How Noticky compares to alternatives

Noticky is not a general-purpose note-taking app. It does not replace Bear, Obsidian, or Apple Notes. It is a sticky note app designed to keep reference material visible while you work. Here is how it compares to tools in that specific category.

Feature	Noticky	Apple Stickies	SideNotes	Tot 2
Float above fullscreen	Yes	No	No	No
Global hotkey	`Cmd+Shift+N`	No	No	No
Markdown WYSIWYG	Yes	No	Yes	No
iCloud Sync	Yes	No	No	Yes
Touch ID lock	Yes	No	No	No
Export (PDF/MD/TXT)	Yes	No	Partial	No
Menu bar app	Yes	No	No	Yes
Price	$6 once	Free	$19.99	Free

For detailed head-to-head comparisons, see Noticky vs Apple Stickies, Noticky vs SideNotes, or the full best sticky note apps for Mac roundup.

Who uses Noticky

Noticky is used by developers, cybersecurity professionals, writers, remote workers, and people with ADHD. The common thread is needing reference material visible at all times without context switching.

Developers

Keep API documentation, environment variables, SQL queries, or error messages visible while coding in VS Code, Xcode, or IntelliJ fullscreen. No tab switching, no split screen. The reference is pinned to your screen.

Cybersecurity professionals

Pin IP addresses, port lists, command sequences, or incident notes above a fullscreen terminal or SIEM dashboard. During active incident response, leaving your monitoring tool to check a note costs time you do not have.

People with ADHD

Context switching is disproportionately disruptive for people with ADHD. A note that disappears when you switch apps is a note that breaks your focus. Noticky notes stay visible permanently, serving as an external working memory that does not rely on you remembering to check it.

Remote workers

Meeting agendas, talking points, and action items floating above Zoom or Google Meet in fullscreen. No scrambling to find your notes when someone asks for your update.

Writers and researchers

Outlines, source links, and key quotes visible while drafting in a fullscreen writing app. Your reference material stays one glance away instead of one swipe away.

Technical details

Noticky is a native macOS application built with Swift, AppKit, and SwiftUI. It is not an Electron app, not a web wrapper, and not cross-platform. It is built specifically for macOS, using macOS-native frameworks.

Window level: Noticky renders notes at a macOS window level that persists across all Spaces, including fullscreen Spaces. This is the same layer where system UI elements like the menu bar operate. Standard apps use NSNormalWindowLevel (level 0), which is Space-bound. Noticky operates above this.

Menu bar architecture: Noticky has no Dock icon and no main application window. It runs as a menu bar agent (LSUIElement), meaning it does not appear in your Cmd+Tab app switcher. This keeps your workspace clean.

Launch performance: The Quick Capture window appears in under 80ms from hotkey press. This is possible because the capture interface is pre-loaded in memory and shown on demand, not created fresh each time.

Storage: Notes are stored locally in the app's container and synced via iCloud using CloudKit. No third-party servers. No account creation.

System requirements: macOS 15 Sequoia or later. Runs on Apple Silicon and Intel Macs.

For more on how macOS handles windows and why fullscreen breaks most note apps, see Floating notes on Mac.

FAQ

What does Noticky do?

Noticky is a macOS menu bar app that creates sticky notes which float above all windows, including fullscreen apps. It solves the problem of notes disappearing when you enter fullscreen mode on macOS. Press Cmd+Shift+N to capture a note from anywhere, and it stays visible on screen no matter what app has focus.

Is Noticky free?

No. Noticky costs $6 one-time with no subscription. All features are included in the purchase price, and all future updates are free. There is no free tier, but $6 covers the full app indefinitely.

Does Noticky work in fullscreen?

Yes. This is Noticky's core feature. Notes remain visible above fullscreen apps because Noticky uses a macOS window level that persists across all Spaces, including fullscreen Spaces. No other sticky note app on macOS does this.

What macOS version does Noticky require?

macOS 15 Sequoia or later. Noticky uses APIs available only in Sequoia and newer to ensure reliable always-on-top behavior.

Is Noticky on the Mac App Store?

Noticky is sold directly through noticky.app via FastSpring. This allows the developer to offer a lower price without the 30% App Store commission.

Who makes Noticky?

Noticky is built by a solo indie developer. It is not backed by a VC-funded company or a large team. One person builds, maintains, and supports the app.

Does Noticky sync notes between Macs?

Yes. Noticky uses iCloud Sync via CloudKit. If you are signed into the same iCloud account on multiple Macs, your notes sync automatically. No setup required.

Can I lock notes with Touch ID?

Yes. Individual notes can be locked with Touch ID. Locked notes display a blurred preview and require biometric authentication to view or edit.

I'm Leonidas, an indie developer building macOS tools. Noticky is my first app -- a $6 sticky notes app where notes stay visible even in fullscreen. noticky.app

Fueling Developer Success: The Power of Continuous Learning

LeoJ — Fri, 13 Oct 2023 09:02:00 +0000

In today's fast-evolving tech landscape, remaining at the forefront of your industry requires more than just a job search. It demands continuous skill enhancement. As the founder of Rico, a platform revolutionizing job hunting by streamlining application processes, I understand the unique challenges that developers face when seeking employment.

Continuous learning isn't merely a buzzword; it's a lifeline for developers. Rico's mission isn't just to simplify the job search process; it's about granting you the precious gift of time to focus on what matters most: skill development.

Here's why continuous learning is your secret weapon as a developer:

Adaptability to the X Degree: The tech world doesn't stay still for anyone. Languages, frameworks, and tools evolve constantly. To stay ahead, developers must master the art of adaptation. Rico frees your time to embrace these changes proactively.
Career Elevation: The more you learn, the more valuable you become. Continuous skill enhancement isn't just about impressing potential employers; it's about taking your career to new heights. Rico empowers you to find the ideal job and invest more in your professional growth.
Unlocking Creativity: The ability to think critically and solve complex problems is what sets exceptional developers apart. By automating the tedious job search process, Rico provides you with more time to nurture creativity and innovation.
Personal Fulfillment: Every line of code you write, and every problem you solve, is a testament to your growth. Learning isn't merely a means to a career end; it's an enriching journey of self-discovery.
Financial Gains: By enhancing your skillset, you pave the way for higher-paying positions. Your investment in learning pays substantial dividends.

Continuous learning isn't an option; it's a core part of your journey as a developer. With Rico in your corner, you gain not only the opportunity to secure the job of your dreams but also the precious freedom to sharpen your skills and advance your career.

As a developer, your path to success is not defined by the jobs you land but by your enduring commitment to learning, evolving, and excelling. Rico is your partner in this journey, automating your job search and granting you the time you need to invest in continuous learning.

Harness your potential, chase your dreams, and embrace the world of boundless knowledge that awaits. Rico: the catalyst for developer success.

By Try Hard

The Birth of Rico - A Journey from Job Seeker to Solution Creator

LeoJ — Thu, 12 Oct 2023 09:00:00 +0000

Sometimes, the brightest solutions emerge from sheer necessity. My journey with Rico began during a pivotal phase in my career, and it's a story I'm excited to share.

In Pursuit of Opportunities:
It all started during my time at BeCode, a period every aspiring developer is intimately familiar with - the job hunt. The last two months of my training were dedicated to a relentless search for internships or job offers, but success remained elusive. I revamped my CV and decided to create a basic version of Rico. The goal? To scrape job listings and filter them based on companies offering internships. Little did I know that this small experiment would later become my key to unlocking countless opportunities.

The Genesis of Rico:
As I fine-tuned my makeshift tool, something unexpected happened. I began discovering numerous job listings that piqued my interest. There was a catch, though - the volume was overwhelming. Sorting through them was a daunting task. To address this problem, I introduced an email automation feature that streamlined my application process. Before I knew it, I found myself going through interviews, more interviews than I'd ever imagined.

4 Interviews for 1 week were a lot for me as a junior.

The Turning Point:
With my internship secured, I temporarily put Rico aside, having achieved my immediate goal. But at the end of my internship, I was faced with the next challenge: finding a job. Job hunting for junior developers can be a formidable task, and this is where the idea for Rico as we know it today was conceived.

Rico's Mission:
Rico's vision is to empower job seekers by providing a streamlined, efficient, and automated solution. It aims to eliminate the hassles of job searching, save time, and open the doors to opportunities that would otherwise remain hidden.

My journey reflects the resilience and creativity every job seeker must muster in a competitive job market. Rico was my response to a problem that many of you have likely encountered. If you're looking for opportunities in the tech industry, Rico is here to simplify your journey and help you reach your goals. Join the waitlist and unlock the power of Rico!

By Try Hard

Avoiding Common Mistakes to Excel in Your Developer Career

LeoJ — Wed, 11 Oct 2023 08:00:00 +0000

In the ever-evolving world of programming, developers, especially juniors, often face significant challenges in their job search and adaptation to a new work environment. Drawing from my personal experience, I wanted to share the common mistakes I've observed throughout my journey and the lessons I've learned from them.

Common Mistakes to Avoid:

Lack of Fundamental Skills: It's common for developers to focus on mastering a specific framework but overlook strengthening their fundamental skills, such as programming, core concepts, and algorithms. These fundamentals are crucial.
Ineffective Communication: Clear communication is essential. No matter how good the code is, if nobody understands how it works, it's ineffective.
Inadequate Research: Research is the key to solving problems. Top developers spend time exploring solutions before diving in.
Inability to Problem-Solve: Sometimes, the challenge lies in finding solutions. Successful developers know how to creatively approach these problems.
Neglecting Self-Valorization: Putting your code into production is crucial. Nothing demonstrates your skills better than working in production. It's a source of pride and proof of competence.
Lack of Networking: The importance of professional connections cannot be underestimated. Networking within the industry can open many doors

Specific Challenges First Job:

Understanding Business Logic: Understanding why and for whom you're coding is essential. Juniors must strive to grasp the business logic behind the code.
Rigor: Programming demands rigor. Minor mistakes can lead to costly bugs. A good developer writes clean, precise code.
Adapting to the Environment: Sometimes, the work environment isn't suitable for a junior. Finding a compatible environment is crucial.
Cultural Fit: Integrating with the team and the company's culture is important. Juniors must adapt to these aspects.
Asking the Right Questions: Before diving into programming, ask questions. Understand the context and user needs.
Human Understanding: Beyond code, human skills are essential. Understanding, showing empathy, and communicating effectively with colleagues and clients is critical.

The job search for a junior developer can be quite challenging. However, every mistake is a learning opportunity. Rico - Job Search Automation can assist you in streamlining your job search, allowing you to focus on your skills and avoid common mistakes. Join our waiting list to discover how Rico can help excel in your developer career.

Revolutionizing Job Searches: How Rico Helps Developers Land Their Dream Jobs

LeoJ — Wed, 11 Oct 2023 00:53:42 +0000

The world of job hunting can be particularly daunting for developers who are just starting their careers. It often involves hours of scouring through job listings, tailoring resumes and cover letters, and tracking application progress. That’s where Rico, the revolutionary job search automation tool, steps in to make the process faster, smarter, and more effective.

Rico is your trusted companion in the journey to kickstart your IT career. It’s designed to cater specifically to junior developers, simplifying the job search process and helping you land your dream job. In this article, we’ll dive into how Rico automates your job hunt and streamlines your path to success as a junior developer.

Traditional Job Hunting Challenges for Junior Developers
Junior developers face unique challenges when looking for job opportunities. These challenges include a lack of experience, limited industry connections, and uncertainty about which roles to apply for. Rico addresses these challenges head-on.

Automated Search & Application
Imagine having a dedicated assistant who not only scans through job listings from various sources but also connects to job platforms using your account credentials, searching on your behalf, and submitting applications on your behalf. That’s exactly what Rico does. It automates both the job search and application process, saving you countless hours of manual work.
Customized Alerts for Junior Developers
Rico allows junior developers to set up customized job alerts based on their specific criteria. Whether it’s a particular role, location, or company, Rico ensures you’re always in the loop about the opportunities that matter most to you at this stage of your career.

Data Security at the Core
We understand that as a developer, you may have concerns about data security. Rico takes advanced security measures to protect your personal and confidential data, especially when connecting to your accounts on job platforms. Your information is encrypted and stored securely, giving you peace of mind as you embark on your job search journey.

How Rico Works for Developers
Rico’s operation is seamless and tailored for junior developers. Here’s how it works:

Connect Your Accounts: You provide Rico with access to your job platform accounts.
Input Your Preferences: You define your job search criteria, focusing on roles suitable for developers, and Rico uses this information to search on your behalf.
Automated Scanning & Application: Rico’s powerful bot continuously scans job listings and submits applications for junior developer positions, saving you time and ensuring accuracy.
Customized Alerts: Rico keeps you informed about new job opportunities tailored to junior developers based on your preferences.
Data Security: Your personal data is protected with robust security measures, even when Rico connects to your accounts.

Join the Revolution and Kickstart Your IT Career
Rico is not just another job search tool; it’s a game-changer for developers aiming to kickstart their IT careers. It gives you the freedom to focus on what truly matters: advancing your career, learning, and growing your skills.

Ready to experience the future of job hunting as a junior developer?
Join the waitlist today and discover the power of automation in your job search.

Don’t miss out on the opportunity to supercharge your job hunt with Rico. Say goodbye to the old way of job searching and embrace the future tailored to developers.