DEV Community: Matias Affolter

🛡️ How I Built a NSFWJS Alternative That's 2.5 Lighter (~1 MB Gzipped) and Runs in ~65 ms (WASM)

Matias Affolter — Thu, 04 Jun 2026 14:01:28 +0000

A field report on shipping a binary SFW/NSFW image classifier for pixagram that runs **entirely in the browser, tuned for the one thing every off-the-shelf model quietly gets wrong: pixel art.

🎯 The itch

I run a Web3 platform for pixel art. People upload sprites, mint them, share them. And the moment you let strangers upload images, you inherit a very old problem: some of those images shouldn't be shown to everyone.

The obvious move is NSFWJS. It's excellent, it's battle-tested, and it runs in the browser. I tried it. Then I looked at what it was doing on my content and realized I was using a sledgehammer to crack a very specific nut.

"I didn't need a model that knows a thousand things about a photograph. I needed one that knows exactly two things about a sprite."

So I built my own. This is the story of how — the good decisions, the one that almost shipped a broken model, and the numbers I ended up with. I've written it so a junior dev can follow the whole thing and a senior one still finds the war stories useful. Where I use jargon, there's a 🔰 In plain terms box right after.

🤔 Why not just use NSFWJS?

NSFWJS is built around a MobileNetV2 backbone, trained on a large corpus of photographic and drawn web imagery, and it returns five categories (Drawing, Hentai, Neutral, Porn, Sexy). That's a fantastic general tool. But three things didn't fit me:

It's photographic. My content is pixel art — hard edges, tiny palettes, no anti-aliasing. A model that learned from photos has never really seen a 160×160 sprite.
It's bigger than my whole problem. Five classes and a ~3.5M-parameter backbone is a multi-megabyte download for a yes/no question.
I only ever ask one question. "Is this safe to show or not?" That's a single threshold, not a five-way softmax I have to interpret.

I wanted something I could embed in my bundle, that ran on-device (no upload, no server round-trip, no privacy headache), and that was trained to understand the medium I actually serve.

📋 What I actually needed

Before writing a line of code, I wrote the spec. It fit on a sticky note:

✅ Binary. sfw vs nsfw, one probability, one threshold.
✅ Tiny. Small enough to base64-embed in an npm package — ideally ~1 MB.
✅ Fast. Real-time-ish on a mid laptop without a GPU. Target: well under 100 ms.
✅ On-device. Runs in a Web Worker via WebAssembly. Nothing leaves the browser.
✅ Pixel-art-aware. The preprocessing has to respect the pixel grid, not smear it.
✅ Self-contained. npm install, import, call classify(). No model-hosting step for the consumer.

Everything below is downstream of that list.

🧠 Choosing a brain that fits in a tweet

I picked MobileNetV4-conv-small-050 from timm. It's ~0.96M parameters — roughly 2.5× lighter than the MobileNetV2 that NSFWJS leans on — and it's one of the strongest architectures per parameter you can pull off the shelf with ImageNet weights.

Then I made it cheaper still: I trained and ran it at 160×160 instead of the usual 224. For a convolutional net, compute scales with the pixel area, so dropping from 224 to 160 cuts the work to roughly half — landing the model around ~65 MFLOPs per image. For a binary decision on a sprite, that resolution is plenty.

🔰 In plain terms: the "backbone" is the pretrained image-understanding part of the model. Starting from one that already learned general vision on millions of photos (ImageNet) means I only have to teach it the last mile — "of the things you already see, which are NSFW?" — instead of teaching it to see from scratch.

🔧 The pipeline (the boring part that matters)

The whole thing is four steps, and each one hands its output to the next:

Train in PyTorch/timm — fine-tune the backbone on a two-folder dataset (nsfw/, sfw/).
Export to ONNX — a portable model format the browser can run.
Quantize — shrink the weights from 32-bit floats to 8-bit integers.
Embed — base64 the quantized model straight into the JS bundle, so there's no separate fetch.

At runtime it's onnxruntime-web, which can run the same model on WebGPU when it's available and fall back to WebAssembly (WASM) on the CPU otherwise.

🔰 In plain terms: WASM lets the browser run compiled code at near-native speed. It's why a neural network can run client-side without melting the tab.

The thing I want to stress for anyone building one of these: the four steps are one chain, and the weakest link decides your accuracy. I learned that the hard way twice — once on quantization, once on preprocessing.

🐇 The quantization rabbit hole (where I almost outsmarted myself)

My first instinct was to go aggressive: if 8-bit is good, 4-bit (Q4) must be better, right? Half the size, the blogs promise 2× speedups, everyone's quantizing LLMs to 4-bit. I almost spent a weekend on it.

Then I actually checked what 4-bit means in ONNX Runtime, and on my own model. Two facts stopped me cold:

ONNX Runtime's 4-bit path is weight-only and only touches MatMul operations (it rewrites them into MatMulNBits). It's a tool built for transformers.
My model, when I counted its operations, is 46 convolutions, one tiny classifier head, and zero MatMuls. A MobileNet is almost pure convolution.

So I ran the 4-bit quantizer on it anyway, just to be sure. It dutifully skipped every single node and handed me back a file that was 100% of the original size. Nothing happened, because there was nothing it knew how to touch.

"Halving a file that already fits in cache doesn't make it faster — it just makes it smaller. Those are not the same win. The 4-bit magic is real; it's just real for a different kind of model than mine."

The memory-bandwidth argument behind 4-bit assumes a huge model whose weights can't fit in fast memory. Mine is ~1 MB — it lives in CPU cache comfortably. So I dropped the fantasy and used uint8, which is exactly what ONNX Runtime recommends for the WASM/CPU path.

🔰 In plain terms: quantization stores each weight in fewer bits (32-bit float → 8-bit int) to shrink and speed up the model. Less precision, smaller file. The trick is doing it without changing the model's answers — which is exactly where I got burned later.

🎨 Pixel art breaks all the rules

Here's the thing nobody warns you about when your domain is pixel art: how you resize the image matters more than almost anything else.

Every model needs a fixed input size, so every image gets resized. For photos, the default — bilinear interpolation, which smoothly blends pixels — is fine. For pixel art, it's destructive: it takes crisp, intentional blocks and blurs them into mush. The thing that makes a sprite a sprite is the first thing bilinear throws away.

The right filter for upscaling pixel art is nearest-neighbor ("pixelated"): it keeps every block sharp.

But here's the trap, and it's the one that bites everyone: the resize at training time and the resize at serving time have to be identical. If you train on crisp nearest-neighbor images and then serve on blurred bilinear ones, the model is seeing a different distribution than it learned. You didn't just lose a little accuracy — you're running a different model than the one you trained.

"A model is only as honest as its preprocessing. Train on crisp pixels, serve on blurred ones, and you've quietly shipped a model you never actually tested."

So I made the resize filter a single source of truth: you choose it once at training time (--interp nearest), it gets stamped into the model checkpoint, the exporter reads it back and bakes it into the preprocessing config, and the browser reads that and resizes the same way. One decision, threaded through the entire chain, impossible to desync.

(One sharp edge worth flagging: in the browser, the cleaner-looking createImageBitmap API can do the resize, but its quality setting is browser-dependent — Firefox has historically ignored the "pixelated" hint. For guaranteed nearest-neighbor everywhere, an old-fashioned <canvas> with image smoothing turned off is the reliable tool.)

⚡ Making it fast (and invisible) in the browser

A classifier that freezes the UI is a classifier nobody ships. So the runtime does a few things to stay out of the way:

🧵 Web Worker by default. Inference runs on a background thread, with an automatic fall back to the main thread where workers aren't available. Same API either way.
📦 Batching. Multiple classify() calls within a few milliseconds get coalesced into a single inference, so the fixed per-call overhead is paid once for the whole batch.
🎒 The model travels with the code. It's base64-embedded in the bundle — one fewer network request, and it works offline.
🖥️ GPU when present, CPU when not. The runtime tries WebGPU and gracefully falls back to WASM, so a uint8 model still reaches the GPU on machines that have one.

The result of all this — small backbone, 160px, uint8, off-thread — is an inference that lands around ~65 ms on a CPU. Fast enough to check an image the moment it's dropped in.

🐛 The bug that almost broke me: "it never says NSFW"

This is the part I almost left out, because it's embarrassing. But it's also the most useful thing in this whole post, so here it is.

Everything was wired up. I deployed it. And it never flagged anything as NSFW. Not once. Clearly-NSFW pixel art sailed right through as "safe."

My first assumption was the worst-case one: the model never learned, or my training data (photographic) didn't transfer to pixel art at all. A wasted model. But before re-training anything, I wrote a tiny sanity-check script — the single most valuable hour I spent on the project. All it does is run the full-precision model and the quantized model on the same image, with the exact preprocessing, in plain Python. No browser, no canvas, no worker. Just: where, precisely, does the answer go wrong?

I ran it on one NSFW sprite. Here's what it told me:

nsfw_pixelart.png
  FP32 : P(nsfw)=0.973   ← the real model is CONFIDENTLY correct
  UINT8: P(nsfw)=0.106   ← the SHIPPED model is confidently WRONG

There it was. The full-precision model was right — 97% sure it was NSFW. The quantized model I'd actually deployed was 89% sure it was safe. Quantization had flipped the answer.

"FP32 said 0.97. The version I shipped said 0.11. The model wasn't wrong — the model I deployed was a different model than the one I trained."

The cause is a classic, and it's specific to this family of networks. MobileNets are built from depthwise convolutions, where each channel has its own little filter and the weight magnitudes vary wildly from channel to channel. I'd quantized with a single scale for each whole weight tensor (per-tensor), which crushed the small-magnitude channels to nothing. The fix is per-channel quantization — give every channel its own scale — which is a single flag (--wasm-quant u8s8, per-channel int8 weights).

🔰 In plain terms: imagine compressing a choir by setting one volume knob for everyone. The loud singers are fine; the quiet ones vanish. Per-channel quantization gives each singer their own knob. For MobileNets, that's the difference between a working model and a broken one.

The deeper lesson wasn't even about quantization. It was that the model you train and the model you deploy are not automatically the same model — export and quantization are transformations that can silently change behavior. A 30-line script that compares them at the boundary is worth more than any amount of staring at training curves.

🏆 The result

Where it all landed:

	NSFWJS (typical)	This
Backbone	MobileNetV2 (~3.5M params)	MobileNetV4-conv-small-050 (~0.96M)
Output	5 categories	binary `sfw` / `nsfw`
Domain	photographic / drawn	pixel art
Size	several MB	~1 MB gzipped
Inference	—	~65 ms on CPU (WASM)
Runs	in browser	in browser, in a worker, offline

Roughly 2.5× lighter, single-purpose, on-device, and — critically — trained and served with preprocessing that respects the medium. It ships as a self-contained npm package: npm install, import { classify }, done.

💡 What I'd tell my past self

The reusable lessons, stripped of my specific stack:

🎯 Match the model to the question. A binary problem doesn't need a five-class model; a sprite doesn't need a photo-scale backbone. Smaller-but-fitted beats bigger-but-generic.
🧮 "Smaller file" and "faster" are different wins. 4-bit shrinks giant models that are memory-bound. A 1-MB CNN is compute-bound and already cache-resident — different problem, different tool.
🔗 Preprocessing is part of the model. Train and serve through the identical pipeline, or you're testing one thing and shipping another. Make it a single source of truth.
🧪 Verify at every boundary. Export and quantization can flip your answers. A tiny full-precision-vs-quantized diff script will save you a day of guessing.
🐛 When it "never fires," suspect the transform, not the model. My model was perfect. The 8-bit copy of it wasn't.

🚀 Try it

This powers content moderation on my pixel-art platform, and it's open. If you're building anything that takes user images in the browser — especially in a niche domain where the big general models don't quite fit — I'd genuinely encourage you to consider training a small, fitted model instead of reaching for the default. It's less work than it sounds, and the result is something you actually understand top to bottom.

Build the thing that knows exactly what it needs to know. 🎨🛡️

Happy shipping.

I Benchmarked LacertaDB & PouchDB — Here's What Happened

Matias Affolter — Thu, 26 Mar 2026 17:29:39 +0000

LacertaDB vs PouchDB: a head-to-head performance comparison of two browser-native document databases, and why your serializer matters more than you think.

The Browser Database Problem Nobody Talks About

Every browser database eventually hits the same wall: serialization.

Your data has to be transformed before it hits IndexedDB, and transformed back when it comes out. Most libraries use JSON. Some use CBOR or MessagePack. The choice of serializer silently determines your throughput ceiling — and most developers never question it.

I built LacertaDB to be the fastest browser-native document database possible. Along the way, I had to build its serializer from scratch too, because nothing on npm was fast enough or complete enough. Then I ran it against PouchDB — the established king of browser databases — to see where things actually stand.

Here are the numbers. No cherry-picking, no synthetic micro-ops. Real document CRUD at scale.

The Benchmark Setup

Both databases ran identical workloads in the same browser tab, same machine, same IndexedDB backend. The test: 5,000 documents with ~200-byte payloads, covering the five operations that matter in a real app:

Bulk Write — insert all documents in a single batch
Read All — retrieve every document
Query (filter) — find documents matching a field condition
Bulk Update — modify every document
Delete All — remove everything

LacertaDB uses batchAdd / getAll / query / batchUpdate / clear.
PouchDB uses bulkDocs / allDocs / find (with pouchdb-find) / bulkDocs / bulkDocs with _deleted.

Both are fair comparisons of each library's recommended bulk API.

The Results

Operation	LacertaDB	PouchDB 7.3	Speedup
Bulk Write	532 ms	2,664 ms	5×
Read All	146 ms	356 ms	2.4×
Query	124 ms	399 ms	3.2×
Bulk Update	101 ms	2,708 ms	26.8×
Delete All	239 ms	2,573 ms	10.8×

The gap ranges from 2.4× to nearly 27×, depending on the operation. Writes and deletes show the biggest difference — and those are precisely the operations where serialization overhead dominates.

Throughput in Context

At 5,000 documents:

LacertaDB sustained ~9,400 writes/sec and ~34,000 reads/sec
PouchDB managed ~1,900 writes/sec and ~14,600 reads/sec

This isn't a marginal difference. For offline-first apps syncing hundreds of records, or Web3 dApps caching blockchain state locally, the gap between "feels instant" and "shows a spinner" lives right in this range.

Why the Gap? It's the Serializer.

PouchDB stores documents as JSON. That's fine for simple objects, but JSON has well-known limitations: no Date, no undefined, no Map, no Set, no RegExp, no typed arrays, no binary data. And JSON.stringify/parse, while native C++ under the hood, still has to traverse every property, escape every string, and produce a text representation that's larger than the source data.

LacertaDB uses TurboSerial, a binary serializer I built specifically for this problem. The design goals were:

Serialize everything JavaScript can hold — not just JSON-safe types
Produce smaller output — binary, no delimiters, no escaping
Be faster than the alternatives — including CBOR and MessagePack

TurboSerial vs MessagePack vs CBOR

I ran TurboSerial against the two established binary serialization formats. The benchmark measures both throughput (ops/sec) and output size across three payload profiles:

Test Case	MessagePack	CBOR	TurboSerial
Small Data (API response)	20,101 ops/s · 34B	112,360 ops/s · 36B	176,991 ops/s · 62B
Medium Data (array of objects)	334 ops/s · 4,093B	3,460 ops/s · 4,168B	5,587 ops/s · 4,809B
Large Data (TypedArray 0.2MB)	711 ops/s · 200,005B	341 ops/s · 200,005B	2,703 ops/s · 200,023B

TurboSerial is consistently 1.5–8× faster than both MessagePack and CBOR across payload sizes. The output is slightly larger on small payloads (it encodes richer type metadata), but the throughput advantage more than compensates — especially at the medium and large data sizes that matter in a database context.

Type Coverage: Where JSON, CBOR, and TurboSerial Diverge

This is the part that rarely makes it into benchmark posts, but it's what actually matters when you're building a real app. Here's what each format can serialize natively:

Type	JSON	MessagePack	CBOR	TurboSerial
Strings, Numbers, Booleans, null	✅	✅	✅	✅
Nested Objects / Arrays	✅	✅	✅	✅
`undefined`	❌	❌	✅	✅
`Date`	❌	❌	✅ (tag)	✅
`Map` / `Set`	❌	❌	❌	✅
`RegExp`	❌	❌	❌	✅
`BigInt`	❌	❌	✅ (tag)	✅
`ArrayBuffer` / TypedArrays	❌	✅	✅	✅
`Int8Array` through `Float64Array`	❌	❌	❌	✅
`Error` objects	❌	❌	❌	✅
`URL`	❌	❌	❌	✅
Sparse Arrays	❌	❌	❌	✅
`NaN`, `Infinity`, `-Infinity`	❌	❌	❌	✅
`-0` (negative zero)	❌	❌	❌	✅

JSON covers about 7 types. CBOR and MessagePack stretch to ~12 with tags and binary extensions. TurboSerial natively handles 20+ JavaScript types — including the edge cases that silently break your data when you use JSON (like undefined being stripped from objects, or Date becoming a string you have to manually parse back).

When your database serializer supports Map, Set, RegExp, and typed arrays out of the box, you stop writing workaround code. Your documents go in, and they come out identical. No reviver functions, no manual reconstruction.

Beyond Raw Speed: What LacertaDB Actually Offers

Performance is one axis. Here's what the full picture looks like against PouchDB:

Feature	LacertaDB	PouchDB
Bundle size (minified)	~110 KB	~200 KB
Serialization	TurboSerial (binary)	JSON
Storage backend	IndexedDB + OPFS + localStorage	IndexedDB (+ adapters)
Query syntax	MongoDB-style, 20+ operators	Mango (pouchdb-find plugin)
Index types	B-Tree, Hash, Full-text, Geo	B-Tree equivalent
Encryption	AES-GCM-256, PBKDF2 Master Key Wrap	❌ (requires plugin)
Aggregation pipeline	`$match`, `$group`, `$sort`, `$lookup`…	❌
Geospatial queries	QuadTree `$near`, `$within`	❌
Full-text search	Built-in with CJK support	❌ (requires plugin)
Caching strategies	LRU / LFU / TTL per collection	❌
Binary attachments	OPFS-backed	Blob-based
CouchDB sync	❌	✅
Node.js / server-side	❌ (browser-only)	✅

The honest tradeoff: PouchDB has CouchDB sync and server-side support. If you need those, PouchDB is the right tool. LacertaDB is browser-native by design — it trades server compatibility for raw performance, smaller bundles, and features you'd otherwise need three plugins to bolt onto PouchDB.

When to Reach for LacertaDB

LacertaDB was built for a specific class of application:

Offline-first PWAs that need to cache and query significant amounts of data locally without UI jank
Web3 dApps that store blockchain state, wallet keys (with real encryption), or NFT metadata client-side
Data-heavy SPAs where the difference between 100ms and 2,700ms on a bulk write is the difference between feeling native and feeling broken
Apps storing rich JavaScript types — if your data model uses Map, Set, Date, typed arrays, or BigInt, you'll stop fighting your serializer

If you need CouchDB replication or server-side rendering, PouchDB remains excellent. But if your database lives in the browser and performance is non-negotiable, LacertaDB is worth a look.

Try It Yourself

npm install @pixagram/lacerta-db

import { LacertaDB } from '@pixagram/lacerta-db';

const lacerta = new LacertaDB();
const db = await lacerta.getDatabase('myapp');
const users = await db.createCollection('users');

// Store a document with types JSON can't handle
await users.add({
  name: 'Alice',
  joined: new Date(),
  preferences: new Map([['theme', 'dark'], ['lang', 'en']]),
  tags: new Set(['admin', 'beta-tester']),
  avatar: new Uint8Array([137, 80, 78, 71]) // PNG header bytes
});

// Query it back — every type is preserved, no revivers needed
const admins = await users.query({
  tags: { $contains: 'admin' }
});

The source is on GitHub, the package is on npm, and the benchmark playground is included in the repo.

LacertaDB is MIT-licensed and built by Pixagram SA in Zug, Switzerland.

A deep dive into LacertaDB

Matias Affolter — Wed, 17 Dec 2025 13:18:17 +0000

LacertaDB: Why We Built a MongoDB-Like Database That Runs Entirely in Your Browser DEMO

How we created a full-featured document database with encryption, indexing, and aggregation pipelines — all running client-side with zero backend.

The Problem Nobody Was Solving

Picture this: You're building a Web3 wallet, an offline-first PWA, or a privacy-focused note-taking app. You need to store sensitive data locally. Your options?

Solution	Problem
`localStorage`	5MB limit, no queries, plaintext only
Raw IndexedDB	Verbose API, no encryption, manual indexing
SQLite WASM	2MB+ bundle, SQL syntax, no native encryption
PouchDB	Sync-focused, no built-in encryption
Dexie.js	Great queries, but no encryption or OPFS

We needed something that:

✅ Stores encrypted documents with zero backend
✅ Supports MongoDB-style queries
✅ Handles binary files (images, PDFs)
✅ Has proper indexes for performance
✅ Works entirely offline
✅ Fits in a reasonable bundle size

Nothing existed. So we built LacertaDB.

What Makes LacertaDB Different

1. 🔐 Military-Grade Encryption, Zero Configuration

// That's it. Your entire database is now encrypted.
const db = await lacerta.getSecureDatabase('vault', '123456');

// Every document is automatically encrypted with AES-GCM-256
await db.createCollection('secrets').add({
  apiKey: 'sk-live-xxx',
  privateNotes: 'This is encrypted at rest'
});

Under the hood:

AES-GCM-256 encryption (same as banks use)
PBKDF2 key derivation with 100,000 iterations
HMAC integrity verification
Constant-time comparisons (no timing attacks)

Most browser databases bolt encryption on as an afterthought. In LacertaDB, it's a first-class citizen — and it actually works when you change your PIN:

// This re-encrypts EVERY document in the database
await db.changePin('oldPin', 'newStrongerPin!');

We've seen "encrypted" databases that lose all your data when you change the password. We fixed that.

2. 🔍 Real MongoDB-Style Queries

Not "inspired by MongoDB." Actually compatible:

// Find active premium users over 18, sorted by signup date
const users = await collection.query({
  $and: [
    { status: 'active' },
    { plan: { $in: ['pro', 'enterprise'] } },
    { age: { $gte: 18 } },
    { email: { $regex: '@company\\.com$' } }
  ]
}, {
  sort: { createdAt: -1 },
  limit: 20,
  projection: { name: 1, email: 1, plan: 1 }
});

20+ operators supported:

Category	Operators
Comparison	`$eq`, `$ne`, `$gt`, `$gte`, `$lt`, `$lte`, `$in`, `$nin`
Logical	`$and`, `$or`, `$not`, `$nor`
Element	`$exists`, `$type`
Array	`$all`, `$elemMatch`, `$size`
String	`$regex`, `$text`

Plus a full aggregation pipeline:

// Sales report grouped by category
const report = await orders.aggregate([
  { $match: { status: 'completed', date: { $gte: startOfMonth } } },
  { $group: {
      _id: '$category',
      revenue: { $sum: '$amount' },
      avgOrder: { $avg: '$amount' },
      count: { $count: 1 }
  }},
  { $sort: { revenue: -1 } },
  { $limit: 10 }
]);

This runs entirely in the browser. No server. No network request.

3. ⚡ Four Index Types for Real Performance

Queries on 10,000 documents without indexes? Slow.
With indexes? Instant.

// B-Tree for range queries and sorting
await collection.createIndex('createdAt', { type: 'btree' });

// Hash for lightning-fast exact matches
await collection.createIndex('email', { type: 'hash', unique: true });

// Full-text search
await collection.createIndex('content', { type: 'text' });

// Geospatial for location queries
await collection.createIndex('location', { type: 'geo' });

The geo index supports real geospatial queries:

// Find coffee shops within 2km
const nearby = await places.query({
  location: {
    $near: {
      coordinates: { lat: 47.3769, lng: 8.5417 },
      maxDistance: 2 // kilometers
    }
  },
  category: 'coffee'
});

4. 📁 Native Binary File Storage with OPFS

Most browser databases choke on files. LacertaDB uses the Origin Private File System (OPFS) — a modern API that gives you a real filesystem:

// Store a document with file attachments
const docId = await collection.add(
  { 
    title: 'Project Proposal',
    author: 'Alice'
  },
  {
    attachments: [
      proposalPDF,     // File object
      coverImage,      // Blob
      spreadsheet      // Another File
    ]
  }
);

// Retrieve with attachments
const doc = await collection.get(docId, { includeAttachments: true });
// doc._attachments = [{ name: 'proposal.pdf', data: Uint8Array, ... }]

Files are stored separately from document data, so your IndexedDB doesn't bloat. And yes, they're encrypted too.

5. 🏗️ Fractal Architecture

LacertaDB follows a "fractal" design where each layer encapsulates complexity:

LacertaDB
└── Database (encryption, settings, migrations)
    └── Collection (CRUD, queries, indexes, events)
        └── Document (serialization, compression, packing)

This means you can use just what you need:

// Full database with collections
const db = await lacerta.getDatabase('app');
const users = await db.createCollection('users');

// Or just fast key-value storage
const prefs = db.quickStore;
prefs.add('theme', { mode: 'dark', accent: '#00ff88' });

Real-World Use Case: Web3 Wallet

Here's how we use LacertaDB for secure key storage in a crypto wallet:

import { LacertaDB } from '@pixagram/lacertadb';

class WalletManager {
  async initialize(userPin) {
    this.lacerta = new LacertaDB();
    this.db = await this.lacerta.getSecureDatabase('wallet', userPin);
    this.wallets = await this.db.createCollection('wallets');

    // Index for fast lookups
    await this.wallets.createIndex('address', { unique: true });
  }

  async createWallet(name) {
    const { privateKey, address } = generateKeyPair();

    // Store encrypted private key in secure vault
    await this.db.storePrivateKey(`${name}-pk`, privateKey);

    // Store public metadata
    await this.wallets.add({
      name,
      address,
      createdAt: Date.now(),
      balance: '0'
    }, { id: name, permanent: true }); // permanent = protected from cleanup

    return address;
  }

  async signTransaction(walletName, tx) {
    // Retrieve decrypted private key
    const privateKey = await this.db.getPrivateKey(`${walletName}-pk`);
    return signWithKey(tx, privateKey);
  }

  async exportBackup(backupPassword) {
    // Export everything, encrypted with a separate password
    return await this.lacerta.createBackup(backupPassword);
  }
}

The private keys are:

Encrypted with AES-GCM-256
Key derived from user PIN via PBKDF2
Never exposed in plaintext
Separate from document storage

This is production code we ship.

Performance That Scales

We benchmarked LacertaDB against common operations:

Operation	1,000 docs	10,000 docs	100,000 docs
Insert (batch)	45ms	380ms	3.2s
Query (indexed)	2ms	3ms	8ms
Query (full scan)	12ms	95ms	890ms
Aggregation	8ms	65ms	580ms

With proper indexes, queries stay fast even at scale. The built-in performance monitor helps you optimize:

lacerta.performanceMonitor.startMonitoring();

// ... do operations ...

const stats = lacerta.performanceMonitor.getStats();
console.log(stats);
// {
//   opsPerSec: 245,
//   avgLatency: '4.12',
//   cacheHitRate: '89.3',
//   memoryUsageMB: '12.45'
// }

const tips = lacerta.performanceMonitor.getOptimizationTips();
// ['Consider adding an index on frequently queried fields']

The Caching Layer Nobody Talks About

Every query doesn't need to hit IndexedDB. LacertaDB includes three caching strategies:

// LRU (Least Recently Used) - default
collection.configureCacheStrategy({
  type: 'lru',
  maxSize: 200,
  enabled: true
});

// LFU (Least Frequently Used) - for hot data
collection.configureCacheStrategy({
  type: 'lfu',
  maxSize: 100
});

// TTL (Time To Live) - for expiring data
collection.configureCacheStrategy({
  type: 'ttl',
  ttl: 60000 // 1 minute
});

Cache hit rates of 80%+ are common, meaning 4 out of 5 queries return instantly from memory.

Schema Migrations Done Right

Your data schema will evolve. LacertaDB has you covered:

const migration = new MigrationManager(db);

migration.addMigration({
  version: '2.0.0',
  name: 'Add user roles',
  up: async (doc) => ({
    ...doc,
    role: doc.isAdmin ? 'admin' : 'user',
    permissions: doc.isAdmin ? ['read', 'write', 'delete'] : ['read']
  }),
  down: async (doc) => {
    const { role, permissions, ...rest } = doc;
    return { ...rest, isAdmin: role === 'admin' };
  }
});

// Migrate forward
await migration.runMigrations('2.0.0');

// Oops, rollback
await migration.rollback('1.0.0');

Migrations run per-document across all collections, with full rollback support.

Event-Driven When You Need It

Hook into document lifecycle events:

collection.on('afterAdd', async (doc) => {
  await syncToCloud(doc);
  analytics.track('document_created', { id: doc._id });
});

collection.on('beforeDelete', async (docId) => {
  const doc = await collection.get(docId);
  await createBackup(doc);
});

// Available events:
// beforeAdd, afterAdd
// beforeUpdate, afterUpdate  
// beforeDelete, afterDelete
// beforeGet, afterGet

Why "Lacerta"?

Lacerta is the Latin word for lizard — specifically the genus that includes the common wall lizard. Why a lizard?

🦎 Adaptable: Lives anywhere, eats anything
🦎 Fast: Moves in bursts of incredible speed
🦎 Resilient: Survives harsh conditions
🦎 Efficient: Cold-blooded = minimal energy waste

That's what we wanted for browser storage: adaptable to any use case, fast when it matters, resilient to failure, efficient with resources.

Plus, we're based in Zug, Switzerland 🇨🇭 — lizards love sunny Alpine rocks.

Getting Started

npm install @pixagram/lacertadb

import { LacertaDB } from '@pixagram/lacertadb';

const lacerta = new LacertaDB();

// Unencrypted database
const db = await lacerta.getDatabase('myapp');

// Or encrypted
const secureDb = await lacerta.getSecureDatabase('vault', 'myPin');

// Create collection and go
const todos = await db.createCollection('todos');
await todos.add({ text: 'Try LacertaDB', done: false });

const pending = await todos.query({ done: false });
console.log(pending);

What's Next

We're actively developing:

🔄 Sync adapters for optional cloud backup
📊 Query planner for automatic index selection
🧪 Schema validation with JSON Schema
🔌 Plugin system for custom index types

Try It Today

📦 npm: @pixagram/lacertadb
📚 Docs: github.com/pixagram/lacertadb
🐛 Issues: We actually respond!

If you're building anything that needs local-first, encrypted, queryable storage in the browser — give LacertaDB a try. We think you'll love it.

Built with 🦎 by Pixagram in Zug, Switzerland

What browser storage challenges have you faced? Drop a comment below! 👇

How We Built an AI That Transforms Your Photos Into Pixel Art in 10 Seconds (And Why It Matters for Web3)

Matias Affolter — Tue, 28 Oct 2025 10:31:55 +0000

TL;DR: We created an AI-powered pixel art generator that preserves facial features while creating authentic retro art. But here's the kicker – pixel art is 100x lighter than regular images, making it perfect for storing forever on the blockchain. Let me show you how we did it. TRY IT

The Problem We're Solving

Picture this: You love NFTs, but uploading a 2MB photo to the blockchain costs you an arm and a leg. Most NFT platforms don't actually store your art on-chain – they just store a link that could break tomorrow. Meanwhile, creating genuine pixel art by hand takes hours, even for professionals.

We thought: What if we could convert any photo into authentic pixel art that's light enough to live permanently on-chain?

That's how Pixagram was born.

The Magic Behind the Curtain

Our AI pipeline is like a sophisticated assembly line, where each station does one specific job really well. Here's what happens when you upload a photo:

Pixagram.io - Social Media Blockchain

Use the social media blockchain — Pixagram — where your artworks become as enduring as diamond. Transform photos into pixel art using pixa.pics, then mint, post, and thrive on our NFT-powered network.

pixagram.io

1. Face Detection & Enhancement (The Foundation)

First, we use InsightFace to detect faces in your image. But we don't just find the face – we actually understand it. The system extracts:

512-dimensional facial embeddings (basically a mathematical fingerprint of your face)
Facial keypoints (eyes, nose, mouth positions)
Age and gender estimates
Facial structure data

Here's where it gets interesting: we crop the face with 30% padding around it (for context), then enhance it through multiple stages:

Resize to optimal dimensions
Sharpen features (1.5x boost)
Enhance contrast (1.1x)
Adjust brightness (1.05x)

Think of this as giving the AI the best possible view of your face before the transformation begins.

2. Dual Embedding System (The Secret Sauce)

Most AI art generators use one type of embedding. We use two working together:

CLIP Embeddings:

These understand the semantic meaning of your face
They know "this is a smiling woman with blue eyes"
Perfect for maintaining identity at a conceptual level

InsightFace Embeddings:

These understand the geometric structure of your face
They know exact distances between features
Perfect for preserving facial accuracy

By combining both, we get the best of semantic understanding AND structural precision.

3. The Transformation Pipeline

Now the real magic happens. We use a modified Stable Diffusion XL pipeline with several specialized components:

a) Custom Pixel Art LORA
We trained a specialized LORA (Low-Rank Adaptation) on authentic pixel art. This teaches the model what genuine pixel art should look like – not just blocky images, but art with proper dithering, limited color palettes, and that nostalgic retro feel.

b) InstantID ControlNet
This maintains facial structure using the keypoints we extracted earlier. It's like drawing a skeleton that the AI must follow – ensuring your eyes stay where your eyes should be.

c) Zoe Depth ControlNet
This preserves the 3D structure of your image. It understands depth – what's in front, what's behind – keeping your photo's spatial relationships intact.

d) IP-Adapter Integration
This injects our dual embeddings directly into the diffusion process through cross-attention. It's constantly whispering to the AI: "remember, this is what the person's face looks like."

4. Post-Processing Polish

After generation, we apply color matching in LAB color space. This ensures skin tones stay consistent with the original photo – no random orange or purple faces.

For faces, we create soft masks with feathered edges, allowing seamless blending between the pixelated transformation and facial features.

The Technical Stack

Here's what powers the system:

- Base Model: Stable Diffusion XL (custom checkpoint: "horizon")
- Face Analysis: InsightFace (AnteLope v2)
- Scheduler: LCM (enables 12-step generation)
- ControlNets: InstantID + Zoe Depth
- Image Encoding: CLIP Vision Model
- Pipeline: Img2Img (preserves structure)

Key Parameters:

Steps: 12 (thanks to LCM scheduler)
CFG Scale: 1.0-1.5 (LCM sweet spot)
Img2Img Strength: 0.55 (balances transformation vs. fidelity)
Identity Preservation: 1.3x (boosted for maximum face accuracy)
Resolution: Auto-optimized to 896×1152 or 832×1216

Why This Matters: The Blockchain Advantage

Here's where things get really interesting. Let's talk numbers:

A typical photo:

Average size: 2-3 MB
On IPFS: Still requires external hosting
Link can break if hosting fails
Expensive to store on-chain

Pixagram pixel art:

Average size: 15-20 KB
That's 100-150x smaller
Can be embedded directly on-chain
Stored forever in the blockchain itself
No external dependencies

Our Blockchain: Built for This

Pixagram runs on a fork of HIVE/STEEM, optimized for social media and NFTs:

72 KB maximum post capacity – perfect for pixel art
3-second block time – near-instant confirmation
Proof-of-Brain consensus – rewards creators
24 elected witnesses – truly decentralized

When you create pixel art on Pixagram, it's not just stored on-chain – it becomes part of the chain. Your art will exist as long as the blockchain exists. No broken links. No lost hosting. Forever.

How It Actually Performs

Let's be real about what this AI can and can't do:

What it excels at:

Portraits with clear facial features
Photos with good lighting
Maintaining facial identity (80-95% similarity)
Creating authentic pixel art aesthetic
Fast generation (10 seconds average)

What's challenging:

Very low-light photos
Extremely complex scenes
Photos where faces are tiny or obscured
Multiple faces (focuses on largest)

We've tested thousands of photos, and the system achieves 80-90% average face similarity, with best cases hitting 95%+.

Try It Yourself

Want to see it in action? We've made it dead simple:

Pixagram.io – Our full platform with blockchain integration
Hugging Face Space – Try the AI without signup

The Hugging Face space lets you experiment with all the parameters:

Adjust identity preservation strength
Control pixel art intensity
Fine-tune depth and structure preservation
Enable/disable color matching

The Bigger Picture

We're not just building an AI art generator. We're building a Web3 social network where:

Every post rewards creators
Art lives forever on-chain
No corporation owns your content
Lightweight pixel art enables true decentralization

The NFT market has 11.6 million users worldwide, but most platforms are either:

Exciting but centralized (like Instagram)
Decentralized but boring (like traditional NFT marketplaces)

Pixagram aims to be both: exciting AND decentralized.

Technical Deep Dive: The Code

For the developers reading this, here's how the core generation works:

# Core pipeline initialization
pipe = StableDiffusionXLControlNetImg2ImgPipeline.from_single_file(
    model_path,
    controlnet=[instantid_controlnet, depth_controlnet],
    torch_dtype=torch.float16
)

# Face analysis
faces = face_app.get(image_array)
face_embeddings = face.normed_embedding  # 512-dim

# IP-Adapter projection
image_embeds = image_proj_model(insightface_embeds)

# Generation with dual ControlNets
result = pipe(
    image=input_image,
    control_image=[face_keypoints, depth_map],
    controlnet_conditioning_scale=[0.85, 0.75],
    added_cond_kwargs={"image_embeds": image_embeds},
    strength=0.55,
    num_inference_steps=12,
    guidance_scale=1.45
)

The key insight? Multi-modal conditioning. We're hitting the model from multiple angles simultaneously:

Text prompts guide style
Depth maps preserve structure
Keypoints maintain facial geometry
Embeddings preserve identity
Img2Img keeps overall composition

What's Next?

We're currently in testnet alpha, with mainnet beta coming in October 2025. Our roadmap includes:

Enhanced multi-face support
More art styles beyond pixel art
Advanced blockchain governance
Creator monetization tools
NFT marketplace integration

Join the Revolution

Whether you're a:

Developer – Fork our code, build on our blockchain
Artist – Create pixel art that lives forever
Crypto enthusiast – Early adopter advantages
Curious human – Just want to pixelate your selfie

We'd love to have you.

Try it now:

Production platform: pixagram.io
Experiment freely: Hugging Face Space
Get in touch: omnibus@pixagram.io

Final Thoughts

The internet promised to make information free and accessible forever. But in practice, links break, servers die, and companies disappear. Blockchain offers a second chance at that promise – but only if we can make it practical.

Pixel art isn't just nostalgia. It's a 100x compression that makes permanent, decentralized storage actually feasible. It's small enough to embed in a blockchain, distinctive enough to be valuable as art, and our AI makes it accessible to everyone.

That's the magic formula: AI accessibility + artistic value + blockchain permanence.

"Create artworks lasting forever on the blockchain while getting rewarded." That's not just our tagline – it's the future we're building.

Come help us build it.

What do you think? Would you want your photos turned into permanent blockchain pixel art? Let me know in the comments!

Tags: #ai #blockchain #web3 #nft #pixelart #machinelearning #stablediffusion #opensource

About Pixagram:
Pixagram SA is a Swiss company (Zug) developing Web3.0 social media infrastructure. Our technology combines AI art generation with lightweight blockchain storage, creating the first truly on-chain social network for pixel art NFTs.

TurboSerial! High-Performance JS Serialization

Matias Affolter — Tue, 02 Sep 2025 10:20:19 +0000

A deep dive into TurboSerial on NPM, a new JavaScript serialization library that outperforms MessagePack and CBOR through SIMD-inspired design, and why it might be your next choice for performance-critical applications.

In the world of web development, especially in performance-critical applications, the way we handle data is paramount. Sending large JSON payloads can be a significant bottleneck. This is where binary serialization formats like MessagePack and CBOR have traditionally stepped in, offering more compact and faster alternatives.

But what if we could push the boundaries of performance even further?

Enter TurboSerial, a new JavaScript serialization library designed from the ground up for extreme speed, inspired by modern, low-level CPU optimizations.

We ran a comprehensive benchmark suite of over 110 tests comparing TurboSerial against the well-established MessagePack (v5) and CBOR (cbor-js). The results were eye-opening.

See For Yourself

We believe in transparency and verifiable results. You can run the exact same benchmark suite in your own browser and see the performance difference firsthand.

Run the interactive benchmark

The Verdict: Compatibility and Speed

When it comes to handling the full spectrum of JavaScript types, the difference is stark. While the established libraries struggle with modern features like BigInt, complex Maps, and circular references, TurboSerial handles them with ease.

Compatibility is only half the story. In performance benchmarks, TurboSerial consistently outperformed the others, especially in scenarios involving large, structured data.

For small and medium-sized JSON-like objects, TurboSerial was consistently the fastest. But its true power was revealed when handling large TypedArrays, where it was dramatically faster than the competition. This isn't magic; it's by design.

What Makes TurboSerial So Fast?

TurboSerial's performance advantage comes from architectural decisions inspired by cutting-edge, low-level libraries like simdjson. It leverages concepts that allow modern CPUs to process data in parallel.

1. SIMD (Single Instruction, Multiple Data)

At its core, SIMD is a CPU feature that allows a single instruction to be executed on multiple data points simultaneously. Think of it as a multi-lane highway versus a single-lane road. Instead of processing one number at a time in an array, TurboSerial's SIMD-optimized routines can process blocks of 4, 8, or even more numbers in a single CPU cycle. This provides a massive throughput advantage for numeric arrays and TypedArrays.

2. Byte Alignment

Modern CPUs are fastest when they can read data from memory addresses that are multiples of 4 or 8. Accessing misaligned data can cause the CPU to perform extra work, slowing down the entire process. TurboSerial is meticulous about aligning data in its internal buffers, ensuring that every read and write operation is as fast as the hardware allows.

3. Inspired by SIMD.js

While the original SIMD.js specification was put on hold, its polyfills and the underlying "branchless" design philosophy were a major inspiration. By designing algorithms that avoid conditional branching (if/else) and instead process data in predictable blocks, TurboSerial minimizes CPU pipeline stalls, keeping the processor fed with data and operating at maximum efficiency.

Getting Started with the API

TurboSerial maintains a simple and intuitive API, making it easy to drop into any project.

import TurboSerial from '@pixagram/turboserial';

const serializer = new TurboSerial();

// Serialize any JavaScript value
const data = {
  string: 'Hello, World!',
  number: 42,
  bigint: 123456789012345678901234567890n,
  array: [1, 2, 3, 4, 5],
  date: new Date(),
  map: new Map([['key', 'value']]),
  typedArray: new Float32Array([1.1, 2.2, 3.3])
};

const serialized = serializer.serialize(data);
const deserialized = serializer.deserialize(serialized);

For power users, the library offers a rich set of configuration options to fine-tune its behavior for specific use cases.

Advanced Configuration

const serializer = new TurboSerial({
  compression: false,           // (Upcoming feature)
  deduplication: true,          // Store duplicate objects/strings once
  shareArrayBuffers: true,      // Share ArrayBuffer references
  simdOptimization: true,       // Enable SIMD-like optimizations for arrays
  detectCircular: true,         // Handle circular references
  memoryPoolSize: 65536         // Initial memory pool size in bytes
});

Conclusion

While MessagePack and CBOR are excellent, established libraries, TurboSerial represents a step forward, leveraging modern hardware capabilities to offer superior performance and wider type compatibility. For applications where every millisecond and every data type counts, TurboSerial is a powerful new contender that is well worth considering for your serialization needs.

The Dark Reality of NFTs: An Obscure and Limited Landscape

Matias Affolter — Fri, 04 Oct 2024 14:50:04 +0000

Non-Fungible Tokens (NFTs) have emerged as one of the most talked-about innovations in digital ownership, creativity, and technology. Yet, despite their widespread visibility, the world of NFTs remains shrouded in complexity, making them difficult to access for the majority of people. This article sheds light on the current constraints within the NFT ecosystem, highlighting the gaps between awareness and action, the gender disparities, and the overwhelming complexity of minting and acquiring NFTs. In the end, we’ll see why NFTs have yet to reach the mainstream and remain confined to niche circles.

“Crypto and NFTs are a path to financial independence, so it’s important that women and girls know about them. When I first heard about blockchain, I didn’t think it was for me. But I realized that it can be an inclusive space for women and people of color. I think crypto has the power to radically advance women’s rights.” – Maliha Abidi, Artist & Author

1. Widespread Awareness but Minimal Engagement

A Global Phenomenon Known by Many, Used by Few

Surveys like those from Statista (2022) show that NFTs are not lacking in awareness. Between 40-50% of internet users globally are aware of NFTs, representing hundreds of millions of people. Countries like the U.S., parts of Europe, and Asia (particularly Japan and South Korea) show even higher rates of awareness, often exceeding 50%.

However, the critical issue lies in translating this awareness into action. Despite millions knowing about NFTs, only a small fraction actively engages with them. Fewer than 1% of those aware of NFTs have actually created or purchased one. This chasm between awareness and engagement points to deeper underlying problems, primarily related to technical barriers and the perceived complexity of the process.

Key Insight:

The widespread knowledge of NFTs doesn't translate into widespread action. Despite high awareness, a minuscule percentage of people are willing or able to engage due to perceived and real barriers.

2. Creating NFTs: Technically Possible, Yet Unlikely

The Technical and Financial Barriers of Becoming a Creator

While platforms like OpenSea have streamlined the process of creating NFTs, the reality remains that fewer than 3-5 million people have ever minted an NFT, a figure that is tiny compared to the vast pool of individuals aware of the concept. Why such a low adoption rate? A few key reasons stand out:

Technical Complexity: Creating an NFT is not as simple as posting an image on Instagram. It involves understanding cryptocurrency wallets, gas fees, blockchain protocols, and other technical aspects, which are intimidating for newcomers.
Financial Barriers: Minting NFTs often incurs costs (gas fees on Ethereum, for example), which further limits participation to those willing to bear these expenses, unlike free-to-use platforms like social media.

Moreover, many NFT creation platforms lack the user-friendliness of everyday apps like LinkedIn or Instagram, further alienating the average user. The current NFT minting experience requires a familiarity with blockchain infrastructure that many people either do not possess or are unwilling to invest time to learn.

Key Insight:

Although it is technically possible to create NFTs, the process is overly complex and costly for the average internet user, making the barrier to entry significantly higher than on mainstream platforms.

3. Acquiring NFTs: A Gendered and Imbalanced Landscape

The Gender Divide in NFT Ownership

While about 15-20 million people globally have purchased or own NFTs, the ownership landscape is notably skewed in terms of gender. Only about 1 in 4 NFT holders are women, which points to a significant gender imbalance in the space. This statistic is troubling when considering the potential for NFTs to democratize digital ownership and creativity across demographics.

This imbalance isn't just about who is buying NFTs; it's also about who feels welcomed and capable within the NFT ecosystem. Many women report feeling alienated or underserved by current platforms, which cater more to male tech enthusiasts and crypto investors.

Buyers Outnumber Creators, But Complexity Remains

There are roughly four times more buyers than creators in the NFT space, but even becoming a buyer comes with its own challenges. For someone unfamiliar with cryptocurrencies, acquiring an NFT can feel unnecessarily complicated, with steps that require setting up a digital wallet, purchasing crypto, navigating decentralized platforms, and managing security risks. This isn’t as simple as making a purchase on Amazon or posting on a social media platform.

Key Insight:

Gender disparity in NFT ownership and the complex process of purchasing an NFT further limit the democratization of this technology, alienating both potential creators and buyers alike.

4. Platform Constraints and Narrow Use Cases

NFT Platforms Are Not Mainstream-Friendly

Despite the potential of NFTs, the platforms that support them remain niche. OpenSea, Rarible, and Foundation dominate the space, but they are complex, highly specialized, and cater to a specific subset of tech-savvy individuals. While social media platforms like Instagram and LinkedIn could potentially open the doors for wider NFT adoption, they do not currently offer easy integration for NFTs.

Limited Functionality Restricts Use Cases

Even for those who do engage, the use cases for NFTs remain limited. Most NFTs are centered around digital art and collectibles, with very few use cases in mainstream or practical scenarios that would appeal to the average person. As a result, the audience is confined to collectors, artists, and crypto enthusiasts, leaving broader applications largely untapped.

Key Insight:

NFT platforms, as they exist today, cater to a very specific, niche audience. Their functionality and user experience are nowhere near the simplicity of mainstream platforms like Instagram or LinkedIn, limiting the potential for broader adoption.

Conclusion: The Unseen Obstacles Hindering NFTs’ Mainstream Adoption

The NFT space, though promising, is still mired in obscurity, complexity, and imbalance. While millions are aware of NFTs, very few are able or willing to engage with them. The barriers to entry, whether through creation or acquisition, are too high for most, and the platforms that dominate the space are inaccessible to the average internet user. Furthermore, gender disparities persist, highlighting the fact that the NFT ecosystem is far from inclusive.

To unlock the full potential of NFTs, platforms must simplify the user experience, eliminate financial and technical barriers, and widen the use cases beyond digital art and collectibles. Without these changes, NFTs will remain a niche technology, overshadowed by the overwhelming complexity that defines it today.

Sources:

Statista, Global NFT Awareness Survey (2022)
NonFungible.com, NFT Ecosystem Report (2022)

🚀 Introducing LacertaDB: A Simple and Powerful JavaScript Database

Matias Affolter — Thu, 03 Oct 2024 08:06:09 +0000

I’m excited to introduce LacertaDB, a new database I’ve designed that’s simple, flexible, and powerful. It's still evolving, but even now, it brings some unique capabilities to the table that I think you'll find fascinating.

Let me walk you through what makes LacertaDB so interesting:

🎯 Key Features:

Effortless Compression & Encryption: Simply by setting the properties _compressed or _encrypted to true, the Document class automatically recognizes the need to compress or encrypt your data. No extra effort required on your part! It handles both packing and unpacking seamlessly.
Supports Various Data Types: Thanks to joyson, you can pack any type of JavaScript data into LacertaDB—from TypedArray, to Errors, and everything JSON supports as well.
Efficient Metadata Storage with LocalStorage: What makes LacertaDB architecturally unique is that it uses localStorage to store metadata for each database, even when multiple collections exist. Though localStorage is capped at 5MB, that’s plenty for metadata. Here’s what we keep track of:
- 📏 Length of documents
- 🆔 IDs of documents
- 📦 Sizes of documents
- 🛡️ Permanence (_permanent property ensures documents don't get deleted during auto-compaction)

This approach allows LacertaDB to quickly retrieve the database state and automatically compact the database without querying IndexedDB—which, while fast, isn’t as speedy as localStorage.

🔧 The Inner Workings

While LacertaDB needs a bit more work, it already performs remarkably well. You can easily pack and unpack hundreds of documents, whether compressed, encrypted, or not, within milliseconds! 🚀

And all of this while managing metadata in a lightweight manner and avoiding unnecessary overhead.

💡 Why Use LacertaDB?

If you're looking for a simple-to-use database that:

Supports any type of JavaScript object 🛠️
Handles data compression/encryption with a single property change 🔒
Allows you to easily manage collections using instance methods 📁

Then LacertaDB might just be what you need!

✨ How to Use It

You can get started by installing it from npm:

npm install lacertadb

Example usage:

import LacertaDB from 'lacertadb';

// Create a database instance and get a (new) collection
const db = new LacertaDB('myDatabase');
const coll = db.getCollection('documents');

// Add a document with encryption and compression
await coll.addDocument({
    _id: 'document1',
    _compressed: true,
    _encrypted: true,
    data: 'Some sensitive data'
}, 'password');

// Display the query result (you'll see it's encrypted)
console.log(await coll.query());

// Display the document as original
console.log(await coll.getDocument('document1', 'password'));

🔍 Want to know more?

Check out the NPM package
or start using LacertaDB in your projects today. Feedback and contributions are always welcome!

If you’ve ever thought, “I just need a simple database to store my JavaScript objects,” look no further. LacertaDB is here to make your life easier. 🎉

“Code is like humor. When you have to explain it, it’s bad.” – Cory House

Give LacertaDB a try, and see how it fits into your next project! 🙌

This database is evolving, but with its ability to compress, encrypt, and handle various data types in milliseconds, I believe it’s a solid choice for projects that need a lightweight and flexible storage solution. 🚀