DEV Community: KAMATIL

Column Selection Is Not an Index: Two Different Ways to Reduce Database Work

KAMATIL — Sat, 17 Oct 2026 18:15:00 +0000

A product list might display a name and a price while each product record also contains a long description, supplier details, and internal notes. Asking for only the displayed fields is a sensible starting point. It does not, by itself, explain how the database finds the products.

Two separate questions matter: which records must the engine locate, and which fields must it return?

Projection controls the fields

Column selection, also called projection, specifies the fields in the result. An application can ask for name and price rather than every field.

This can reduce the amount of data materialized, serialized, and transferred. Whether it also reduces disk reads depends on the storage layout and execution path. A smaller response is not proof that the database performed less physical I/O.

iniBase provides a concrete example. Its documentation describes separate files for columns and a columns option in its TypeScript read API. That makes the relationship between requested fields and storage particularly visible. It still does not establish the cost of every filtered query.

An index helps locate records

Now imagine looking for a particular product code among many records. Returning only two fields does not automatically prevent a scan of the field used in the filter.

An appropriate index can provide a way to locate matching entries without examining every record. SQLite's query-planning documentation illustrates this distinction through scans, indexed lookups, and covering indexes. A covering index contains the data needed for a query and can avoid an additional table lookup.

These techniques can work together: an access path helps find records, while projection limits the requested fields. Neither technique alone describes the complete query plan.

Compare two different screens

For a broad export of product names and prices, reading a small number of columns may be useful. For a lookup of one rare product code, the way records are located may dominate. Sorting, filters, caches, and the number of matching rows can change the outcome.

That is why "column-based" and "indexed" are not interchangeable performance labels. A storage choice can fit one access pattern well and still involve compromises for another.

Measure the work your application actually does

Start with two requests against the same dataset: one returning complete records and one returning only the fields the screen uses. Keep filters, ordering, pagination, and durability settings fixed.

Then vary the selectivity of the filter separately. Include a request that matches very few records and one that matches many. Record latency, response bytes, CPU time, and peak process memory. Distinguish a cold start from a warmed cache; do not label a run "cold" unless the relevant cache state is actually controlled.

Also separate database timings from HTTP serialization and network time. A faster database call does not guarantee a faster end-to-end request, and smaller allocated disk usage does not establish lower peak RAM.

Carry the distinction into the CMS

iniContent, the Nuxt-based CMS above iniBase, is an example of where these questions become practical: a table screen and a detailed editor can need different fields. Whether a particular screen sends a projected request must be checked in its implementation; the database capability alone does not prove that it does.

For clarity, iniContent's client is Apache-2.0, while its backend API is proprietary.

The useful habit is to ask what work each layer avoids, then measure it. Requesting fewer fields and finding fewer records are both valuable ideas, but they solve different parts of the problem.

Technical references

SQLite query planning, including covering indexes: sqlite.org/queryplanner.html

iniBase storage description and read API: inicontent/inibase

iniContent architecture and licensing: inicontent/inicontent

Meet iniSON: A Lightweight Alternative to JSON for Modern Applications

KAMATIL — Thu, 15 Oct 2026 00:12:03 +0000

Discover how iniSON simplifies data serialization, reduces storage overhead, and powers a growing ecosystem of developer tools, including iniBase and iniContent.

Introduction: Do We Really Need All That JSON?

JSON (JavaScript Object Notation) has become the universal language of modern applications. From REST APIs to configuration files and databases, developers rely on JSON to exchange and store structured information.

Its simplicity, readability, and broad compatibility have made it an industry standard.

But JSON has an often-overlooked disadvantage: its syntax introduces storage overhead.

Every object contains quotation marks, colons, commas, and braces. Although these characters serve an important purpose, they also consume additional bytes.

For individual API responses, the difference may seem insignificant. However, when applications store millions of records or repeatedly serialize complex objects, even small inefficiencies deserve attention.

This raises an interesting question:

What if we could represent JavaScript objects using less syntax without sacrificing their structure?

That's the idea behind iniSON, an open-source serialization library designed as a lightweight alternative to JSON. GitHub

What Is iniSON?

iniSON (Inison) is a TypeScript-based serialization library that provides an alternative way to convert structured JavaScript data into strings and reconstruct it afterward.

Rather than relying on JSON's conventional syntax, iniSON uses a more compact representation that removes unnecessary quotation marks and escapes special characters when needed.

Its primary objective is straightforward:

Store structured data more efficiently while keeping serialization simple for developers.

Consider a standard JSON object:

{
  "name": "Alice",
  "age": 28,
  "city": "New York",
  "active": true
}

With iniSON, the same information can be represented more compactly:

{name:Alice,age:28,city:New York,active:true}

Notice the difference.

The property names no longer require quotation marks, and ordinary string values can be stored without surrounding quotes.

The result is a more compact representation that remains recognizable to anyone familiar with JavaScript objects.

Of course, reducing syntax doesn't automatically guarantee better performance in every situation. Actual savings depend on the data, and serialization speed must be evaluated independently.

Nevertheless, iniSON offers an interesting approach for applications where compact, structured storage matters.

Getting Started With iniSON

One of iniSON's advantages is its straightforward JavaScript API.

Install the package using npm:

npm install inison

Then import the library:

import Inison from "inison";

const user = {
  name: "Alice",
  age: 28,
  city: "New York",
  hobbies: ["Coding", "Reading"],
  active: true
};

// Serialize
const serialized = Inison.stringify(user);

console.log(serialized);

// Deserialize
const restored = Inison.unstringify(serialized);

console.log(restored);

The library exposes two principal operations:

Inison.stringify() converts structured data into its serialized representation.
Inison.unstringify() reconstructs the serialized data into a JavaScript value.

iniSON also supports nested objects, arrays, and escaping special characters, making it suitable for more than just simple key-value structures.

Developers can explore the implementation, tests, and benchmarks directly in the official GitHub repository.

Why Storage Efficiency Matters

Modern software systems generate enormous amounts of structured data.

An e-commerce platform might store products, customers, inventory records, and transactions.

A content management system might handle thousands of pages, components, configuration objects, and metadata records.

A business management application might continuously process operational information.

In each case, data serialization is a small but important component of the overall architecture.

Reducing unnecessary storage overhead can potentially provide several advantages, including smaller serialized payloads, reduced disk consumption, and more efficient processing of certain data structures.

However, serialization is only one part of the equation.

A production application also needs reliable data storage, indexing or efficient retrieval strategies, concurrency control, validation, and suitable APIs.

This is where iniSON becomes particularly interesting: it is part of a broader ecosystem of developer-focused technologies.

Beyond Serialization: Meet iniBase

While iniSON focuses on representing structured data efficiently, iniBase addresses a different challenge:

How can developers build applications with a capable relational database without necessarily depending on a separate database server?

iniBase is an open-source, TypeScript-based, file-oriented relational database management system.

Instead of requiring an external database service, iniBase manages data using files on disk.

Its architecture emphasizes efficient memory usage, structured data management, and developer-friendly APIs.

Among its capabilities are relational table operations, validation, selective column retrieval, caching, optional compression, and transactional durability mechanisms.

Importantly, iniBase includes iniSON as a dependency, demonstrating how compact serialization can fit into a larger database architecture. GitHub

A Database That Works With Your Application

Getting started with iniBase is simple:

npm install inibase

Create a database instance:

import Inibase from "inibase";

const db = new Inibase("myDatabase");

Retrieve records:

const users = await db.get("users");

Or request only specific fields:

const users = await db.get(
  "users",
  undefined,
  {
    columns: ["name", "email"]
  }
);

This API allows developers to interact with relational data directly from TypeScript without writing SQL for these operations.

For developers building Node.js applications, internal management systems, content platforms, or specialized backend services, iniBase offers an alternative worth exploring.

Its file-oriented design can be particularly interesting in deployment environments where infrastructure simplicity and control over storage are priorities.

Like any database technology, however, its suitability depends on workload requirements, concurrency patterns, operational needs, and performance testing.

Explore iniBase: https://github.com/inicontent/inibase

From Database to Complete Platform: Introducing iniContent

A serialization library solves how data is represented.

A database solves how data is stored and retrieved.

But developers building complete applications need much more.

They need authentication, APIs, content management, reusable components, and interfaces through which users can interact with their data.

This is the problem that iniContent aims to address.

iniContent is a headless content management system built around iniBase, combining a modern application interface with structured data management.

Built with Nuxt, it provides a foundation for managing content and application data without starting every project from scratch.

More Than a Traditional CMS

Unlike content management systems focused exclusively on articles and blog posts, iniContent is designed to accommodate broader application requirements.

Its capabilities include database administration, structured content management, REST APIs, authentication, rich-text editing, and customizable page components.

Developers can also extend its interface through Nuxt and define custom content blocks.

The platform provides a foundation for building websites, administration interfaces, and data-driven applications.

iniContent's public documentation also describes the use of iniSON-serialized parameters in its REST API, establishing a practical connection between the serialization library and applications built with the platform. GitHub

Built for Developers Who Want Flexibility

One of iniContent's central design goals is to provide an application foundation without eliminating developer control.

For example, a developer building an inventory-management application needs more than a collection of database tables.

The application may also require an administrative interface, access control, product management, custom workflows, and ways to connect external services.

Instead of developing all these components independently, developers can use iniContent as a starting point and extend it according to their requirements.

The same approach can be applied to e-commerce administration, business management platforms, content-driven websites, and other data-intensive applications.

The result is a more integrated development workflow built around a common technology ecosystem.

Explore iniContent: https://inicontent.com

Three Technologies, One Development Philosophy

Although iniSON, iniBase, and iniContent solve different problems, they share a common direction: simplifying application development while keeping efficiency and flexibility in focus.

Technology	Primary purpose	What it offers
iniSON	Data serialization	A compact alternative to JSON
iniBase	Data persistence	A file-based relational database
iniContent	Application and content management	A headless CMS powered by iniBase

These technologies operate at different levels of application architecture.

iniSON focuses on data representation.

iniBase focuses on persistent data management.

iniContent focuses on building and managing applications around that data.

Developers can explore each project independently or consider how their capabilities complement one another.

This modular approach is important because not every application needs the same tools.

A developer who only needs compact serialization can use iniSON.

Someone building a TypeScript backend with file-based persistence can evaluate iniBase.

A team requiring a complete content-management and application foundation can explore iniContent.

Together, they illustrate an approach to software engineering that emphasizes practical tools rather than unnecessary complexity.

Is iniSON a Replacement for JSON?

Not necessarily.

JSON remains an excellent choice for interoperability, public APIs, and systems requiring broad compatibility across programming languages.

Its extensive ecosystem and standardized behavior are major strengths.

iniSON is better understood as an alternative for situations where developers control the serialization and deserialization process and want to explore a more compact representation.

There are also trade-offs to consider.

Smaller serialized strings do not automatically mean faster parsing, lower total memory consumption, or smaller compressed files.

Developers should benchmark realistic datasets and verify compatibility before adopting a serialization format in production.

The goal is not to replace JSON everywhere.

The goal is to give developers another option when JSON's trade-offs do not perfectly match their requirements.

The Bigger Picture: Building Software With Fewer Unnecessary Layers

Software development has become increasingly dependent on complex infrastructure.

Even relatively small applications may involve database servers, authentication providers, content management tools, backend APIs, and multiple external services.

These technologies offer significant advantages, but every additional dependency also introduces configuration, maintenance, and operational considerations.

Projects such as iniSON, iniBase, and iniContent explore another direction.

They demonstrate how developers can rethink familiar architectural components and build tools around specific goals such as storage efficiency, manageable infrastructure, and flexibility.

Rather than assuming that every application requires the same architecture, this ecosystem encourages developers to evaluate the actual needs of their projects.

Sometimes a conventional relational database is the right choice.

Sometimes a managed backend provides the best development experience.

And sometimes a lightweight, file-oriented architecture can offer compelling benefits.

The important thing is having choices.

Conclusion: Small Optimizations, Bigger Possibilities

iniSON began with a simple idea: structured data does not always need the full syntactic overhead of JSON.

That idea extends naturally into a broader discussion about how modern applications store data, manage content, and organize their infrastructure.

With iniBase providing a file-based relational database and iniContent offering a development platform built around it, developers have an opportunity to explore a connected ecosystem designed with efficiency and flexibility in mind.

Whether you are experimenting with alternative serialization formats, building a custom backend, or developing a complete content-management application, these projects offer interesting technologies to investigate.

Explore the ecosystem, examine the source code, and decide what works best for your next project.

Get Started

iniSON — Lightweight data serialization

GitHub · npm

iniBase — File-based relational database

GitHub · npm

iniContent — Headless CMS and application platform

Official Website · GitHub

iniSON and iniBase are MIT-licensed open-source projects. The iniContent client repository is available under Apache 2.0, while its backend API is proprietary.

Suggested SEO title: iniSON: A Lightweight JSON Alternative Powering iniBase and iniContent

Meta description: Discover iniSON, a lightweight alternative to JSON, and explore how its compact serialization approach connects with iniBase and the iniContent headless CMS.

Meet Inibase: a file-based TypeScript database with column storage

KAMATIL — Wed, 14 Oct 2026 22:10:59 +0000

An article listing usually needs a title and a slug. The full article body can wait until someone opens the page.

That distinction is a useful way to introduce Inibase: a file-based database written in TypeScript that stores columns in separate files and lets you select the fields you want to read.

I'm the creator of Inibase. In this article, I'll walk through a small example and explain some of the design's tradeoffs.

A database inside your application

Inibase runs in your Node.js application and persists data on the filesystem. You don't start a separate database server to use it.

It supports schemas, relations, column selection, caching, optional gzip compression, and an explicit transaction API. Its API uses JavaScript objects rather than SQL strings.

File-based storage still needs a suitable home: your deployment must provide writable, persistent storage. A temporary filesystem in a short-lived function is not a durable database location.

Create a small article database

For this example, use Node.js 22 or later on macOS or Linux. Windows users should check the repository's Unix utility requirements; WSL is one option.

In a fresh directory, install the version used for this example:

npm init -y
npm install inibase@3.8.0

Create demo.mjs:

import Inibase from "inibase";

const db = new Inibase("article-demo");

await db.createTable("articles", [
  { key: "title", type: "string", required: true },
  { key: "slug", type: "string", required: true },
  { key: "body", type: "string" },
]);

await db.post("articles", {
  title: "Getting started with Inibase",
  slug: "getting-started-with-inibase",
  body: "This is the full article content.",
});

const articles = await db.get("articles", undefined, {
  columns: ["title", "slug"],
});

console.log(articles);

Run it once:

node demo.mjs

This example creates a table, inserts an article, and requests its title and slug without requesting the body. It is an initial setup script, not an idempotent migration: use a fresh database directory when repeating the complete example.

Why store columns separately?

Inibase organizes storage into databases, tables, and column files.

For a listing page, selecting two columns can avoid reading the article body column. That is especially interesting when bodies are much larger than titles and slugs.

The practical benefit depends on the workload: row count, field sizes, compression, filesystem behavior, and caching all matter. Column selection alone does not establish that one database is faster than another.

Updates also involve a tradeoff. On a plain table, an update rewrites the affected column files. Inibase offers an opt-in update log that appends update frames instead, with later compaction and additional restrictions. Start with the basic storage path, then evaluate logging against your actual write pattern.

What happens if a write fails?

Writing a row across multiple column files raises an obvious question: what if the process stops halfway through?

Inibase documents a journal and recovery protocol for crash-atomic single-table data mutations. Its default full durability mode uses fsync; the guarantees depend on the operating system and filesystem honoring those operations.

It also provides begin, commit, and rollback for explicit multi-table transactions. The current transaction model has important limits, including one mutation per table per transaction and no read-your-writes behavior. Cross-table operations outside a transaction do not acquire its atomicity guarantees automatically.

The durability documentation explains the scope and limitations in detail.

Where I would evaluate it

Inibase is worth exploring if you want a TypeScript API, file-based persistence, and control over which columns an application reads. A small content application is one concrete workload to try.

For applications built around frequent indexed lookups, heavy concurrent writes, or richer transaction semantics, compare alternatives using representative data. SQLite and other established databases are valuable baselines.

Inibase is MIT-licensed. You can find installation instructions, examples, and benchmark methodology in the GitHub repository.

Try the example with your own content structure. What read or write pattern would you want to see tested next?