Actionbase for Postgres/MySQL: When Likes, Views and Follows Stop Scaling

Minseok Kim — Tue, 10 Feb 2026 13:00:00 +0000

If your likes/follows/views tables are hitting any of these, this post is for you:

Shard by user? Counting likes on an item scatters across shards.
Shard by item? Listing a user's likes scatters instead.
Cache invalidation logic that keeps growing.
Reverse lookups and counts becoming a consistency problem.

Actionbase doesn't solve all database problems. But scaling "who did what to which target" tables — likes, views, follows, wishlists, subscriptions — is exactly what it was built for. It's been serving 1M+ requests/min in production at Kakao.

This post shows how a likes table maps to Actionbase's edge model — and where it fits next to Postgres/MySQL.

If you haven't hit the wall yet, stick with your relational DB. A table, some indexes, a cache — that works for a long time.

From a Likes Table to an Edge

CREATE TABLE user_likes (
  user_id BIGINT NOT NULL,
  item_id BIGINT NOT NULL,
  created_at TIMESTAMP NOT NULL,
  PRIMARY KEY (user_id, item_id)
);

CREATE INDEX idx_user ON user_likes (user_id, created_at DESC);
CREATE INDEX idx_item ON user_likes (item_id, created_at DESC);

In Actionbase, the same data is an edge — who did what to which target:

table: user_likes    # (what)
source: LONG         # user_id (who)
target: LONG         # item_id (target)
properties:
  created_at: LONG   # epoch millis
indexes:
  - recent           # created_at DESC

100 → like → 200 (created_at: 1707300000)

This is a unique edge use case: one user, one like, one item. The edge key is (source, target).

Designing Writes for Reads

In a relational database, you serve new read patterns by adding indexes, caches, and tuning queries as the workload evolves.

Actionbase does it upfront: at write time, materialize the read-optimized structures you'll need for GET/COUNT/SCAN.

One write updates the edge, reverse lookup, counts, and sort indexes. Reads become lookups.

OUT = user → items, IN = item → users

SQL → Actionbase

Edge lookup

SELECT * FROM likes
 WHERE user_id=100 AND item_id=200

GET source=100, target=200

List (forward / reverse)

SELECT * FROM likes
 WHERE user_id=100
 ORDER BY created_at DESC

SELECT * FROM likes
 WHERE item_id=200
 ORDER BY created_at DESC

SCAN start=100, direction=OUT, index=recent
SCAN start=200, direction=IN,  index=recent

Count

SELECT COUNT(*) FROM likes
 WHERE user_id=100

SELECT COUNT(*) FROM likes
 WHERE item_id=200

COUNT start=100, direction=OUT
COUNT start=200, direction=IN

No aggregation. No cache. No scatter queries across shards.

What Moves, What Stays

Domain data — user profiles, product catalogs, orders — stays in Postgres/MySQL. The high-volume interaction tables move to Actionbase. Start with one table: the one causing the most pain. At Kakao, that was the Gift wish list.
Under the hood, Actionbase currently runs on HBase. A lighter alternative backed by SlateDB is in progress.

GitHub: kakao/actionbase

Actionbase: One Database for Likes, Views, and Follows

Minseok Kim — Sun, 08 Feb 2026 15:55:56 +0000

Every social platform needs the same features — likes, views, follows, bookmarks. And every team builds them from scratch, hitting the same walls: fan-out writes, slow counts, inconsistent reads.

Actionbase is an open-source database that treats user interactions as a first-class data model. It exposes a REST API — just HTTP calls to read and write. It's been serving 1M+ requests per minute in production at Kakao, the company behind KakaoTalk.

The Problem

A simple "like" button touches more than you'd think:

Did this user already like this post? → edge lookup
How many likes does this post have? → count
Show all posts this user liked, newest first → scan

With a general-purpose database, you're computing these on every read. At scale, that means slow queries, cache invalidation headaches, and duplicated logic across teams.

How Actionbase Works

Every interaction is modeled as a graph edge:

user-123 → like   → post-456
user-123 → follow → user-789
user-123 → view   → product-012

Who did what to which target.

When a write comes in, Actionbase precomputes all derived data — forward edges, reverse edges, indexes, and counts — in a single operation. Reads are just lookups.

Quick Start

docker run -it ghcr.io/kakao/actionbase:standalone

Runs server (port 8080) in background, CLI in foreground. Load sample data:

load preset likes

This creates 3 edges:

Alice ── likes ──> Phone
Bob ──── likes ──> Phone
Bob ──── likes ──> Laptop

Query — precomputed, just read:

get --source Alice --target Phone               # Alice → Phone
scan --index recent --start Bob --direction OUT  # Bob's likes
scan --index recent --start Phone --direction IN # Phone's likers
count --start Alice --direction OUT              # 1
count --start Phone --direction IN               # 2

See It in Action

What does it look like in a real app? Here's a social media demo powered by Actionbase — likes, follows, feeds, all backed by precomputed reads.

What's Next

This is the first post in the Actionbase Stories series. Upcoming posts will cover patterns for adopting Actionbase into real running systems — from gradual migration to async processing to CQRS integration.

Actionbase wasn't built complete from day one. It was deployed early and evolved under production pressure — surviving incidents, earning trust, and adding verification layers along the way. Those stories are coming too.