DEV Community: Swaraj Puppalwar

Introducing LioranDB Cloud Dedicated Instances: 2 vCPU, 4 GiB RAM & 150 GB Storage for Just ₹8/Hour

Swaraj Puppalwar — Wed, 21 Oct 2026 06:45:50 +0000

Today, I am excited to introduce LioranDB Cloud Dedicated Instances, a managed database hosting solution built for developers, startups, SaaS applications, and backend services.

At Lioran Developer Solutions, we have been working on building our own developer infrastructure, starting with LioranDB, our NoSQL document database developed in Rust.

And now, with LioranDB Cloud Service (LCS), developers can deploy their own dedicated database instances without having to manage the underlying infrastructure.

Our dedicated plan starts at just ₹8 per hour! 🇮🇳

What Do You Get for ₹8/Hour?

We wanted to provide developers with dedicated database resources, predictable pricing, and managed infrastructure.

Here is what our dedicated database instance includes:

Resource	Dedicated Instance
Pricing	₹8/hour
CPU	2 vCPU cores
Memory	4 GiB RAM
Storage	150 GB
Internal nodes	4
Partitions	8
Backups	Daily
Maximum retained backups	7
Backup retention	7 days
Database engine	LioranDB v2
Infrastructure	Managed by LioranDB Cloud

All of this is available through our managed database cloud platform.

No need to manually configure servers, install database binaries, or handle routine database infrastructure management.

You can focus on building your application while LioranDB Cloud manages the database environment.

Dedicated CPU and Memory Resources

Unlike shared database hosting, where multiple customers compete for the same resources, our dedicated plan provides an allocated environment with:

2 vCPU cores and 4 GiB RAM.

This configuration is designed for developers and startups that need more resources for their backend applications.

Whether you are developing a SaaS product, CRM, dashboard, internal application, or API backend, having dedicated resources can help deliver more predictable performance.

Of course, actual throughput depends on your workload, document sizes, indexing, query complexity, and concurrency.

150 GB of Storage

Storage is one of the most important considerations when deploying a database.

With LioranDB Cloud Dedicated Instances, we are offering 150 GB of storage.

This gives developers room to store application documents, user records, business data, and other structured information.

As your application grows, database storage becomes increasingly important.

Our goal is to make storage capacity and database management straightforward for developers.

4 Internal Nodes and 8 Partitions

One of the interesting parts of our dedicated database architecture is how we organize the database internally.

Our dedicated configuration includes:

4 internal nodes
8 partitions

This architecture is designed to support partitioned data management and distribute database workloads across internal components.

Rather than treating the database as one large, monolithic processing unit, we are developing LioranDB around a partition-aware architecture.

Our long-term goal is to improve concurrency, resource utilization, and scalability as workloads grow.

These internal nodes and partitions are part of the database architecture and should not be confused with four independent physical servers or an automatic high-availability guarantee.

Daily Backups With 7-Day Retention

A database is not just about storing documents or achieving high benchmark numbers.

Protecting application data is equally important.

That's why our dedicated instances include daily backups.

Our backup policy includes:

One scheduled backup per day.
A maximum of 7 retained backups.
A retention period of 7 days.

This gives developers access to recent recovery points if they need to restore data from an earlier backup.

Backup retention is an important part of our managed hosting offering, and we will continue improving our backup and recovery infrastructure.

Simple, Hourly Pricing

We wanted to make pricing easy to understand.

Our dedicated database instance costs ₹8 per hour.

Here is what that looks like over different usage periods:

Usage duration	Estimated cost
1 hour	₹8
24 hours	₹192
7 days	₹1,344
30 days	₹5,760
31 days	₹5,952

These estimates assume continuous hourly billing and exclude any applicable taxes or additional charges.

With hourly pricing, developers can better understand the cost of running their database infrastructure.

Who Is This Plan For?

We are building LioranDB Cloud Dedicated Instances for developers and teams that want managed database hosting without handling the underlying server infrastructure.

Some of the applications we are targeting include:

SaaS applications: Store customer information, application configurations, subscriptions, and other business data.

CRM platforms: Manage customer records, contacts, activities, and application documents.

Backend APIs: Power Node.js, TypeScript, and other backend applications with a document database.

AI applications: Store user profiles, conversation metadata, configurations, and application records.

Startup products: Give small engineering teams a dedicated database environment without requiring them to operate their own database servers.

Building India's Developer Infrastructure 🇮🇳

LioranDB Cloud is part of our larger mission at Lioran Developer Solutions.

We want to build developer infrastructure from India, including databases, object storage, authentication systems, and other backend services.

Our vision is to reduce dependency on foreign developer infrastructure while giving developers more choices for building and deploying their applications.

We know that building reliable database infrastructure takes time.

Performance, durability, security, backups, recovery, and long-term stability are all critical.

And we are continuously working to improve each of these areas.

Try LioranDB Cloud

If you are a backend developer, startup founder, or engineering team looking for a managed NoSQL document database, I would really appreciate it if you explored LioranDB Cloud.

We are still growing, improving our infrastructure, and gathering feedback from developers.

Your feedback helps us understand what needs to be improved and what matters most in real-world applications.

LioranDB Cloud Dashboard: https://app.liorandb.com

Documentation: https://docs.liorandb.com

Official Website: https://liorandb.com

Thank you to everyone supporting our journey.

We are building something ambitious, one release, one deployment, and one developer at a time. ❤️

Swaraj Puppalwar

Founder & CTO, Lioran Developer Solutions

Building India's Developer Infrastructure 🇮🇳

[Boost]

Swaraj Puppalwar — Wed, 21 Oct 2026 06:40:02 +0000

Swaraj Puppalwar

Oct 21

LioranDB v2 Alpha Is Here! 15+ Days in Production, 15K Ops/sec, and Our First Cloud Users

#database #rust #devops #mongodb

4 min read

LioranDB v2 Alpha Is Here! 15+ Days in Production, 15K Ops/sec, and Our First Cloud Users

Swaraj Puppalwar — Wed, 21 Oct 2026 06:39:50 +0000

Today, October 21, 2026, I am really excited to announce that LioranDB v2 Alpha has officially launched!

We actually launched it two days ago, on October 19, and I wanted to share our progress, production experience, performance benchmarks, and everything we have achieved so far.

After spending more than a year developing my own NoSQL document database, seeing it running in production and powering real applications is a completely different feeling.

And damn, the experience has been crazy!

15+ Days of Production Testing Without a Crash

Before announcing LioranDB v2 Alpha, we had already been testing the database in a production environment for more than 15 days.

During this testing period, LioranDB ran continuously without a crash, while delivering great performance with efficient memory and CPU usage.

One of our most exciting observations was its resource consumption.

On a VPS with 2 vCPU cores, LioranDB was running with approximately:

100,000 documents
345 MB RAM usage
2 vCPU cores available
15+ days of continuous production testing without a crash

For a database engine that we have been developing from scratch in Rust, these results were incredibly encouraging.

Of course, we still have a lot of optimization, stability testing, and improvements ahead of us, but seeing these numbers in our own production environment was a huge milestone.

I Migrated My Own Backends From MongoDB to LioranDB

This is probably the most exciting part for me personally.

I am now using my own database in my backends!

I migrated my backend applications from MongoDB to LioranDB, and so far, everything has been running smoothly.

The database is performing well, memory usage is efficient, CPU utilization is under control, and the overall experience has been great.

Just imagine spending more than a year building a database, fixing crashes, optimizing memory, rewriting components, and testing millions of documents.

And then, one day, you actually replace MongoDB in your own applications with the database you built.

That feeling is something else. ❤️

For me, LioranDB is no longer just a development project. It is becoming infrastructure that I actually depend on.

Performance Benchmarks: 15,000 Operations Per Second!

Now, let's talk about performance.

During our VPS benchmarking, LioranDB reached approximately 15,000 operations per second.

Here is the breakdown:

Metric	Observed throughput
Write operations	7,000 writes/sec
Read operations	8,000 reads/sec
Combined throughput	15,000 ops/sec
VPS CPU allocation	2 vCPU cores

15K operations per second on a VPS!

That was crazy as hell for us.

These are observed results from our own testing, not a claim that every workload or deployment will achieve the same throughput. Performance depends on document size, concurrency, query patterns, hardware, and other factors.

We are continuing to work on improving performance, memory efficiency, and long-running stability.

Our goal is not just to achieve impressive benchmark numbers. We want to build a database that developers can trust with their real applications.

We Also Launched LioranDB Cloud Service (LCS)!

Alongside the database engine, we have launched LioranDB Cloud Service (LCS), our managed database hosting platform.

Developers can now create and manage their own LioranDB instances without having to manage the database infrastructure themselves.

And we have already reached our first small but meaningful milestone!

8 developers have registered on LioranDB Cloud, and 4 of them are already using LioranDB in their backends and projects.

I know these numbers might look small compared to established database companies.

But for me, they mean a lot.

We spent so much time developing the engine, fixing issues, testing stability, and building the cloud infrastructure.

Now, seeing other developers actually create instances and integrate LioranDB into their projects is an incredible experience.

We are finally moving beyond development and into real-world usage.

And that is exactly what we need: real developers, real applications, real workloads, and genuine feedback.

What's Next? LioranDB v2 Alpha Stable

Our next major milestone is already planned.

LioranDB v2 Alpha Stable is scheduled to launch on December 29, 2026.

Until then, our focus will remain on:

Improving long-running stability and reliability.
Optimizing memory and CPU efficiency.
Fixing issues discovered through real production workloads.
Improving the developer and cloud experience.
Gathering genuine feedback from early adopters.
Making LioranDB more reliable for real-world applications.

We still have a long journey ahead of us.

There will be bugs, performance bottlenecks, architectural challenges, and probably many more sleepless nights debugging Rust code.

But that's part of building infrastructure from scratch.

Building India's Developer Infrastructure 🇮🇳

I started developing LioranDB with a vision of building developer infrastructure from India and reducing dependency on foreign infrastructure providers.

Through Lioran Developer Solutions, we are working toward building our own database, object storage, authentication systems, and other backend infrastructure.

LioranDB is one part of that bigger vision.

We are still early, and I know there is a lot of work left before we can compete with established database technologies.

But every successful deployment, every performance improvement, and every developer who tries LioranDB brings us one step closer.

Thank You!

I genuinely want to thank everyone who has supported this journey.

To the developers who registered on LioranDB Cloud, the early users who trusted our database with their projects, and everyone who shared feedback or encouraged us, thank you so much!

After more than a year of development, seeing my own database running in my backends and now in other developers' applications is something I cannot fully describe.

We have come a long way, but this is only the beginning.

LioranDB v2 Alpha is here. Let's keep building! ❤️

If you are a backend developer, I would really appreciate it if you gave LioranDB a try and shared your genuine feedback.

Try LioranDB Cloud: https://app.liorandb.com

Documentation: https://docs.liorandb.com

Website: https://liorandb.com

Thank you for being part of this journey.

Swaraj Puppalwar

Founder & CTO, Lioran Developer Solutions

Building India's Developer Infrastructure 🇮🇳

Building India's Own NoSQL Document Database | My 1.5-Year Journey with LioranDB 🇮🇳

Swaraj Puppalwar — Sat, 17 Oct 2026 16:39:08 +0000

The DPDPA Act says Indian data should stay in India, and we should have complete control over it. But when we use MongoDB or any other database, we don't have that complete control over our data.

I've been developing a completely regional NoSQL document database for the globe, from India.

It's been 1.5 years in database development, and I've learned many things, failed many times, and bounced back a lot.

On this LinkedIn account, I keep sharing my journey, posts, achievements, and each and every detail.

I'm also making a Discord developer/founder community where we can connect, support each other, and support our government's Make in India initiative. 🇮🇳

I'm planning to start managed database hosting for LioranDB, for SaaS, CRM, AI apps, etc., with support for up to 100K documents.

I'll be offering 500 ops/s, which includes:

250 writes per second (WRPS)
250 reads per second (RPS)

And it's just ₹1 per hour.

The first 7 early birds will get it at ₹0 per hour by using the code BUILDER100 while creating an instance.

Managed Database Hosting: https://app.liorandb.com

Complete Documentation: https://docs.liorandb.com

Join our Discord Community: https://discord.com/invite/WsWWThjPMp

Swaraj Puppalwar: A Marathi Interview About My Coding Journey at 15 | September 2023

Swaraj Puppalwar — Mon, 12 Oct 2026 18:46:03 +0000

लहान वयात अनेक संगणक कोडींग कौशल्य प्राप्त करणारा स्वराज पुप्पलवार...

Translation: Swaraj Puppalwar, who acquired multiple computer programming skills at a young age.

On September 20, 2023, a Marathi-language interview featuring me was published on YouTube by Swachata Mitra Gaurav Shamkule.

I was 15 years old at the time, a school student from Chandrapur, Maharashtra, who had been exploring programming since the age of 11.

The interview focused on my early interest in computers, programming skills, and journey into software development.

Watch the Original Interview

Original title: लहान वयात अनेक संगणक कोडींग कौशल्य प्राप्त करणारा स्वराज पुप्पलवार...

Published: September 20, 2023

Language: Marathi

Interview by: Swachata Mitra Gaurav Shamkule

Video: https://youtu.be/yQY-F071LbE

My Programming Journey in 2023

By 2023, I had already spent several years learning programming, experimenting with different technologies, and developing small software projects.

My early learning included Python, Java, C/C++, HTML, CSS, JavaScript, and Node.js.

Most of my learning came from curiosity, experimentation, and building projects independently.

I was interested not only in writing code but also in understanding how software worked behind the scenes.

This interview was one of the early opportunities I had to share that interest publicly.

Looking Back From 2026

Three years later, my focus has expanded significantly.

I'm currently the Founder & CTO of Lioran Group, working through Lioran Developer Solutions on database systems and developer infrastructure.

One of my primary projects is LioranDB, a NoSQL document database written in Rust.

My work now involves storage engines, B+Trees, MVCC, write-ahead logging, indexing, memory management, concurrency, crash recovery, performance benchmarking, and managed database hosting.

The transition from learning programming languages to engineering database infrastructure has involved plenty of failures, debugging sessions, architectural changes, and lessons.

And there's still a lot to learn.

Why I'm Preserving This Interview

I'm sharing this interview on DEV Community as part of documenting my journey in computer science and software engineering.

It represents an earlier chapter, when I was simply a student fascinated by programming.

Today, I'm working toward a larger goal of building developer infrastructure from India.

The projects have changed, the problems have become more complicated, and my understanding of engineering continues to evolve.

But the curiosity that started everything remains.

Swaraj Puppalwar

Founder & CTO, Lioran Group

Chandrapur, Maharashtra, India

GitHub: https://github.com/UltronTheAI

Website: https://lioran.group

Originally interviewed in Marathi, published September 20, 2023.

Tags: #programming #career #computerscience #developers

Prompt Engineering for Business Decision‑Making: Mental Models and Practical Workflows

Swaraj Puppalwar — Sun, 11 Oct 2026 11:00:40 +0000

Introduction

Artificial Intelligence is no longer a futuristic buzzword; it is a daily collaborator for managers, analysts, and founders. Yet the most common obstacle isn’t the technology itself—it’s the way we ask the AI to help us. Prompt engineering, the craft of turning a business intent into a clear, actionable request, can turn a vague spreadsheet into a strategic playbook.

This article distills the most actionable concepts from the open‑access guide Prompt Engineering for Business Decision‑Making and shows you how to apply them immediately, without writing a line of code.

1. The Bridge Mental Model – Prompt as a Translation Layer

Think of a prompt as a translator that converts three things:

Business Intent – the problem you want solved (e.g., “What is the risk of entering the Southeast Asian market?”).
Domain Context – the relevant data, terminology, and constraints (e.g., “Regulatory environment, local competition, and currency volatility”).
AI Capability – the LLM’s ability to reason, synthesize, and generate text.

Bridge Analogy – Just as a bridge must be engineered for load, span, and material, a prompt must be engineered for clarity, control, and trustworthiness.

When you design a prompt, ask yourself three questions:

Bridge Question	Prompt Design Equivalent
What load does the bridge need to carry?	What decision or insight do you need?
What span must it cover?	What data and context must be included?
What material will hold up under stress?	What constraints, role‑play, or verification steps will keep the output reliable?

Quick Checklist – Is Your Prompt a Strong Bridge?

Intent statement – a single sentence that names the decision.
Context payload – key facts, numbers, or documents.
Control mechanisms – role, format, constraints, or verification steps.

If any of these are missing, the bridge is weak and the AI may “fall off” into hallucination.

2. Structuring Prompts for Clarity and Control

The guide identifies three proven structures that work like pre‑engineered bridge components:

2.1 Role‑Play

“You are a senior market analyst with 15 years of experience in emerging markets.”

Why it works: It primes the model with a perspective, biasing the output toward the tone and depth you need.

2.2 Step‑by‑Step (S‑B‑S) Framework

“First, list the top three regulatory hurdles. Second, estimate the cost impact of each. Third, rank them by severity.”

Why it works: Breaking the request into atomic steps forces the model to produce a logical chain rather than a lump‑sum answer.

2.3 Constraint Framing

“Provide the answer in a markdown table, limit each row to 80 characters, and cite at least one public source per claim.”

Why it works: Constraints keep the output tidy and immediately usable.

Sample Prompt – Market‑Entry Risk Assessment

You are a senior market analyst specialized in Southeast Asian expansion.

**Goal:** Produce a risk assessment for entering the Indonesian e‑commerce market.

**Step‑by‑Step:**
1. Identify three macro‑economic risks.
2. For each risk, give a short (≤30‑word) description.
3. Quantify the potential revenue impact (‑10% to +10%).
4. Summarize the top mitigation strategy.

**Constraints:** Output as a markdown table with columns: Risk, Description, Impact, Mitigation.

Running this prompt in a low‑code chat UI (e.g., Microsoft Teams Copilot, Notion AI) yields a ready‑to‑paste table for your next board deck.

3. Boosting Insight Quality – Advanced Prompt Techniques

3.1 Few‑Shot Examples

Provide 2‑3 short examples of the desired output before the actual request. This sets a pattern the model can replicate.

Example 1:
| Risk | Description | Impact | Mitigation |
|------|-------------|--------|------------|
| Currency volatility | … | -3% | Hedge with forward contracts |

Now produce the same format for the new market.

3.2 Chain‑of‑Thought (CoT)

Ask the model to explain its reasoning before giving the final answer. This surfaces hidden assumptions.

“Explain the reasoning you used to rank the regulatory risks before presenting the table.”

3.3 Self‑Critique Loop

After the first answer, ask the model to review its own output for completeness and bias.

“Check the table for any missing major risk categories and add them if needed.”

These techniques are inexpensive (just a few extra lines) but dramatically increase factuality and relevance.

4. Guardrails – Trustworthiness & Ethics Checklist

Even the best‑crafted prompt can produce biased or inaccurate results. Embed a lightweight validation step:

Validation	Prompt Add‑On
Factuality	“Cite a public source for each claim; if none is available, note ‘no source found’.”
Bias Scan	“Highlight any statements that could reflect regional bias and suggest a neutral rewrite.”
Compliance	“Confirm that the recommendation complies with GDPR and local data‑privacy laws.”

Add these as the final step in your S‑B‑S flow. The model’s own self‑critique, combined with a human spot‑check, creates a simple governance loop.

5. Embedding Prompts into Everyday Workflows

5.1 Low‑Code Integration

Chat‑ops: Use Slack/Teams bots to trigger a prompt with a slash command (/risk-assess Indonesia). The bot returns the markdown table directly in the channel.
Dashboard Widgets: Tools like Retool or Power BI can call OpenAI’s API via a connector, feeding the latest market data into the prompt and refreshing a KPI card.
Document Automation: In Notion, create a template page with a Prompt Block that pulls in project‑specific variables (budget, timeline) and generates a “Decision Summary” section.

5.2 Decision‑Support Playbook Template

Stage	Prompt Action	Output Format
Define	“State the business decision in one sentence.”	Plain text
Gather	“List the three most recent data sources relevant to the decision.”	Bullet list
Analyze	Apply the S‑B‑S prompt (role‑play + constraints).	Markdown table
Validate	Self‑critique + source check.	Checklist
Present	Summarize insights in a 3‑bullet executive brief.	Plain text

Copy‑paste this table into your meeting notes and replace the placeholder prompts with the ones from sections 2‑3.

6. From Prompt to Decision – A Mini‑Case Study

Scenario: A product manager wants to prioritize three feature ideas for a SaaS analytics tool.

Intent – “Prioritize features based on revenue impact and implementation effort.”
Context – Provide a CSV of historical feature adoption rates and a rough effort estimate.
Prompt (role‑play + CoT):

   You are a senior product strategist.

   Using the attached data, rank the three proposed features (A, B, C) by expected net revenue impact.
   First, compute the projected adoption increase (percentage). Then, multiply by average revenue per user.
   Finally, subtract the estimated development cost.

   Output a markdown table with columns: Feature, Projected Revenue, Development Cost, Net Impact, Recommendation.

Self‑Critique Add‑On: > “Verify that the revenue calculation used the correct ARPU figure and that costs are expressed in the same currency.”
Result: A concise table that can be pasted straight into the next sprint planning deck.

The manager saves hours of manual spreadsheet work and gains a transparent, auditable rationale for the prioritization.

7. Scaling Prompt Practices Across an Organization

Create a Prompt Library – Store vetted prompts in a shared Notion or Confluence page, tagged by use‑case (risk, sizing, sentiment).
Run Prompt‑Workshops – Quarterly 1‑hour sessions where teams practice the S‑B‑S framework on real problems.
Governance Dashboard – Track metrics such as prompt reuse rate, validation pass‑rate, and time‑saved per decision.
Iterative Improvement Loop – After each major decision, capture what worked, update the prompt, and log the change.

By treating prompts as reusable assets rather than ad‑hoc queries, you embed AI into the decision culture sustainably.

Conclusion

Prompt engineering is not a technical specialty reserved for data scientists; it is a decision‑making skill that anyone who writes a brief can master. By applying the bridge mental model, structuring prompts with role‑play, step‑by‑step, and constraints, and layering advanced techniques like few‑shot examples and self‑critique, you can extract reliable, actionable insights from LLMs and embed them directly into your everyday workflows.

The concepts, checklists, and playbooks presented here are distilled from the free, open‑access guide Prompt Engineering for Business Decision‑Making. For a deeper dive—including full comparison tables, detailed governance frameworks, and additional real‑world scenarios—explore the complete ebook.

Read the full guide online for free: Prompt Engineering for Business Decision‑Making

I Found an Interview of Myself From 3 Years Ago. I Had No Idea What Was Coming.

Swaraj Puppalwar — Wed, 07 Oct 2026 14:11:34 +0000

On September 20, 2023, a small YouTube channel uploaded an interview with me.

The title was:

“लहान वयात अनेक संगणक कोडींग कौशल्य प्राप्त करणारा स्वराज पुप्पलवार...”

Roughly translated:

“Swaraj Puppalwar, who acquired multiple computer coding skills at a young age.”

It has 723 views.

And honestly, I had almost forgotten this existed.

Watching it again in 2026 feels strange.

At that point, I loved programming. I had been coding for years, experimenting with different technologies and building whatever interested me.

But I had absolutely no idea where that curiosity was going to take me.

I didn't know that a few years later I'd be spending my nights thinking about storage engines, WALs, B+Trees, MVCC, indexing, durability, backpressure, distributed systems, and why a database server is using only 20% of my CPU when I desperately want it to suffer more.

I didn't know LioranDB would exist.

I didn't know I'd end up writing a database engine in Rust.

I didn't know I'd start Lioran Developer Solutions.

I didn't know I'd become obsessed with the idea of building developer infrastructure from India.

Back then, programming itself was the exciting part.

Today, the exciting part is building systems.

And I think that's the biggest difference.

Three years is a ridiculous amount of time

When you're young, three years sounds small.

In software, it's enormous.

You can go from:

“I'm learning how computers work.”

to:

“Why is my secondary-index pipeline periodically dropping write throughput to zero?”

Very quickly. Apparently. :)

There wasn't some master plan connecting those two versions of me.

Mostly, I just kept building.

One project made me curious about another problem.

That problem led deeper into the stack.

Eventually I stopped being satisfied with only using infrastructure.

I wanted to understand it.

Then I wanted to build it.

The funniest part

If I could sit beside the version of myself in that interview, I probably wouldn't give him some dramatic piece of life advice.

I'd just say:

Keep building. It gets way more interesting.

And maybe:

Learn Rust earlier. You're going to need it.

The original interview is still sitting on YouTube with its glorious 723 views.

So I'm putting it here before the algorithm buries this archaeological artifact permanently.

[Embed the interview here]

See you again in three years.

AI‑Powered Personal Knowledge Management: A Practical Blueprint for Knowledge Workers

Swaraj Puppalwar — Tue, 06 Oct 2026 11:29:59 +0000

Why Personal Knowledge Management Matters in the Age of Information Overload

Every day we ingest hundreds of articles, videos, Slack threads, and meeting recordings. The biggest productivity bottleneck isn’t the lack of information – it’s the inability to turn that information into actionable insight. Personal Knowledge Management (PKM) is the discipline that bridges that gap. When you pair PKM with Large Language Models (LLMs), you get a semantic assistant that can:

Capture raw content with minimal friction.
Organize it into a living knowledge graph.
Retrieve the exact fragment you need, even if you don’t remember the exact wording.
Act on insights automatically (e.g., create tasks, draft emails, generate reports).

The open‑access guide AI‑Powered Personal Knowledge Management walks you through a repeatable Capture → Organize → Retrieve → Act workflow. Below are the most actionable mental models and hands‑on practices you can start using today.

1. The Four‑Layer PKM Mental Model

Layer	Purpose	Typical Artifacts	AI Role
1️⃣ Raw Capture	Funnel everything you encounter.	Screenshots, PDFs, audio clips, web clippings.	OCR, speech‑to‑text, auto‑summarization.
2️⃣ Processed Notes	Convert raw data into atomic, searchable pieces.	Markdown snippets, bullet‑point summaries, tags.	LLM‑driven paraphrasing, key‑point extraction.
3️⃣ Knowledge Graph	Connect related ideas and surface hidden patterns.	Bidirectional links, metadata, embeddings.	Embedding generation, similarity search, auto‑linking.
4️⃣ Action Layer	Turn insight into concrete output.	Tasks, reminders, code snippets, SOPs.	Prompt‑based task generation, workflow automation.

Think of the model as a pipeline: each layer adds structure and meaning, and each AI service you plug in amplifies the signal while reducing noise.

2. Designing a Flexible PKM Architecture

Choose a Core Tool – Most creators settle on Obsidian, Roam Research, or Notion. The guide recommends a tool‑agnostic approach: store the canonical data as plain Markdown files in a Git‑backed folder. This gives you:
- Version control.
- Easy migration.
- Compatibility with external scripts.
Add an AI Service Layer – Use a local LLM (e.g., Ollama, LM Studio) or a hosted API (OpenAI, Anthropic). Keep the API key in a vault (1Password, Bitwarden) and expose it to your automation scripts via environment variables.
Create a “Processing” Folder – Inside your repo, create raw/, notes/, graph/, and actions/. Scripts will move files forward as they mature.
Define Naming Conventions – ISO‑8601 timestamps for raw captures (2024-10-06_0830_article.md) and slugged titles for notes (2024-10-06_0830_article-why-pkm-matters.md). Consistency makes batch operations trivial.

3. AI‑Enhanced Capture: From Reading to Raw Data

3.1 One‑Click Web Clipping

Install a browser extension (e.g., MarkDownload for Chrome) that saves the page as Markdown.
Pipe the output to a small Node.js script:

// save-clip.js
const fs = require('fs');
const path = require('path');
const content = process.argv[2]; // markdown string passed from extension
const ts = new Date().toISOString().replace(/[:.]/g, '-');
fs.writeFileSync(path.join('raw', `${ts}_clip.md`), content);

Now every clip lands in raw/ automatically.

3.2 Turning Audio into Text

Use Whisper (open‑source) for local transcription:

whisper "meeting.m4a" --model base --output_format txt --output_dir raw/

The resulting .txt file is ready for the next stage.

3.3 Instant Summarization with LLMs

A one‑liner Python helper can generate a 3‑sentence abstract:

import os, openai, json

def summarize(file_path):
    txt = open(file_path).read()
    response = openai.ChatCompletion.create(
        model="gpt-4o-mini",
        messages=[{"role": "system", "content": "Summarize in three sentences."},
                  {"role": "user", "content": txt}]
    )
    return response['choices'][0]['message']['content']

print(summarize('raw/2024-10-06_0830_article.md'))

Add the summary to the top of the raw file – it becomes the first line of the Processed Note later.

4. Organizing with Knowledge Graphs and Embeddings

4.1 Atomic Note‑Taking

The guide stresses the Zettelkasten principle: one idea per note. After you have a raw file, run a “splitting” script that:

Detects headings.
Generates a separate Markdown file for each bullet point.
Assigns a unique ID (20241006-001).

4.2 Semantic Enrichment

Generate Embeddings – Use sentence‑transformers to create a 384‑dim vector for each note.
Store in a Vector DB – Pinecone, Weaviate, or a local Qdrant instance.
Auto‑Link – For each new note, query the DB for the top‑3 similar vectors and insert bidirectional [[link]] markdown references.

from sentence_transformers import SentenceTransformer
from qdrant_client import QdrantClient

model = SentenceTransformer('all-MiniLM-L6-v2')
client = QdrantClient(path='./qdrant')

text = open('notes/20241006-001.md').read()
vec = model.encode(text).tolist()
client.upsert(collection_name='pkm', points=[{'id': 1, 'vector': vec, 'payload': {'path': 'notes/20241006-001.md'}}])

Now you have a personal knowledge graph that surfaces connections you would otherwise miss.

5. Quality, Trust, and Privacy Checklist

✅	Question	Action
Data Ownership	Is the raw content stored locally or in a third‑party cloud?	Prefer a self‑hosted Git repo; encrypt backups with `gpg`.
LLM Hallucinations	Does the generated summary contain facts not present in the source?	Run a verification prompt: “List only the statements that appear verbatim in the source.”
Access Control	Who can read the PKM repository?	Use a private GitHub repo with 2‑FA; restrict API keys to read‑only.
Retention Policy	How long do you keep raw captures?	Archive older raw files after 6 months; keep processed notes indefinitely.
Bias Monitoring	Are the LLM outputs reflecting personal bias?	Periodically audit a random sample with a peer review checklist.

Following this checklist keeps your system trustworthy and compliant with GDPR‑style principles.

6. From Insight to Action: Automating Workflows

6.1 Task Generation Prompt

You are an assistant. From the following note, extract any implied actions and output them as a JSON array of tasks with fields: title, due_date (optional), and related_note_path.
---
[NOTE CONTENT]

Feed the note to the LLM; parse the JSON and push tasks into Todoist via its API.

6.2 Reminder Bots

A simple Zapier (or n8n) flow:

Trigger: New file added to actions/.
Action: Create a calendar event in Google Calendar.
Action: Send a Slack DM with the task summary.

The result is a closed‑loop: you capture, the system surfaces an action, and you get a timely reminder.

7. Scaling and Evolving Your PKM System

Challenge	Solution
Growing Volume	Periodic vector pruning – keep only the most recent 10 k embeddings; archive older ones to cold storage.
New Data Types	Add a media layer (e.g., `raw/images/`) and run an image‑to‑text model (BLIP) to generate captions before note creation.
Team Collaboration	Export selected vault sections as a shared Obsidian Publish site; keep the personal core private.
Tool Fatigue	Adopt a single‑command entry point (`pkm sync`) that orchestrates capture, processing, and graph updates.

Regularly revisit the 30‑day mastery plan from the guide: set weekly milestones (e.g., “automate audio transcription”, “populate first 100 embeddings”).

8. Quick‑Start Checklist (First 48 Hours)

Create a Git‑backed vault with the four folders (raw/, notes/, graph/, actions/).
Install the capture pipeline – browser extension → save‑clip.js.
Set up Whisper for audio → raw/.
Run the summarizer on a sample article and move the result to notes/.
Spin up a local vector DB (Qdrant) and index the note.
Create a Zapier flow that creates a Todoist task from any file in actions/.
Document the process in a README.md inside the repo – this is your meta‑knowledge.

Complete these steps and you’ll have a working AI‑augmented PKM pipeline that you can iterate on.

Conclusion

Personal Knowledge Management is no longer a manual, siloed activity. By layering AI services on top of a disciplined capture‑organize‑retrieve‑act workflow, you can turn the daily flood of information into a personal intelligence engine. The patterns, scripts, and checklists above are distilled from the free, open‑access ebook AI‑Powered Personal Knowledge Management. If you want a deeper dive—complete workflow templates, evaluation metrics, and a 30‑day mastery blueprint—check out the full guide:

Read the full guide online for free: AI‑Powered Personal Knowledge Management

Happy building, and may your notes always lead to action!

From Manual to Automated: A Practical Blueprint for Small‑Business Owners

Swaraj Puppalwar — Fri, 02 Oct 2026 10:43:32 +0000

Why No‑Code Automation Is a Game‑Changer for Small Businesses

Running a boutique agency, a solo‑consultancy, or a micro‑e‑commerce shop means you wear many hats. The majority of your week is spent on repetitive admin work—copy‑pasting leads into a spreadsheet, sending invoice reminders, or syncing calendars. In 2026 these tasks are no longer a necessary drain on your time because no‑code automation platforms (Zapier, Make, Airtable, etc.) let you stitch together existing SaaS tools without writing a single line of code.

The payoff is two‑fold:

Time reclaimed – every automated minute adds up to hours per month that can be reinvested in revenue‑generating activities.
Consistency & error reduction – a rule‑based workflow executes the same way every time, eliminating the human slip‑ups that cost money and reputation.

The following framework distills the core mental models and hands‑on steps from the free guide No‑Code Automation for Small Business Growth and gives you a ready‑to‑use roadmap.

1. The Automation Mental Model: Trigger → Action → Enrichment

Think of every workflow as a pipeline:

[Trigger] → [Action] → [Enrichment (optional)] → [Final Action]

Trigger – the event that starts the flow (e.g., a new HubSpot contact, a form submission, a new row in Airtable).
Action – the first automated response (e.g., create a task in Asana, send a Slack notification).
Enrichment – optional steps that add value, such as calling an AI model to generate a summary or looking up a customer tier.
Final Action – the end‑point that completes the business need (e.g., send an invoice, update a CRM field).

Visualising workflows this way helps you spot missing links, unnecessary loops, and opportunities for AI‑powered enrichment.

2. Diagnostic Checklist – Spotting Low‑Hanging Fruit

Before you dive into a platform, run this quick audit. Mark each item with ✅ (already automated) or ❌ (candidate for automation).

#	Repetitive Task	Frequency	Current Pain Point	Automation Potential
1	Capture leads from a website form	30‑50/day	Manual copy‑paste to CRM	✅/❌
2	Send welcome email after sign‑up	Immediate	Drafting each email	✅/❌
3	Notify sales when a high‑value deal is created	Real‑time	Missed Slack alerts	✅/❌
4	Reconcile daily sales totals	End of day	Spreadsheet errors	✅/❌
5	Follow up on unpaid invoices	Weekly	Forgetting to send reminders	✅/❌

How to use the checklist

List all admin tasks that occur at least weekly.
Score the pain (time spent, error risk) on a 1‑5 scale.
Prioritise items with a pain score ≥ 3 and a clear trigger.
Pick the first three items and prototype them.

3. Choosing the Right No‑Code Stack

Feature	Zapier	Make (Integromat)	Airtable (Automations)
Ease of entry	★★★★★ (guided UI, many templates)	★★★★ (visual builder, steeper learning curve)	★★★ (requires Airtable base design)
Complex branching	Limited (filter + paths)	Powerful (routers, iterators)	Basic (conditional actions)
Built‑in data store	No (needs external DB)	No (needs external DB)	Yes (tables act as DB)
Pricing for < 5,000 tasks/mo	Free tier (100 tasks) → $20/mo for 2,000	Free tier (1,000 operations) → $9/mo for 10,000	Free tier (1,200 runs) → $10/mo for 5,000
Best fit	Simple one‑step automations (lead capture, email alerts)	Multi‑step, data‑intensive flows (order processing, inventory sync)	Workflows that live inside a relational base (project tracking, content calendars)

Decision rubric (score 0‑3 per criterion, total out of 12):

Complexity of workflow – does it need branching or loops?
Data residency – do you already store data in Airtable?
Budget constraints – how many tasks/operations per month?
Team skill set – is a visual flow easier for non‑technical staff?

Pick the platform with the highest total that aligns with your immediate use‑case.

4. Building Your First Automation – A 5‑Step Framework

Below is a concrete example: When a new contact fills the “Free‑Consultation” form on Webflow, automatically create a HubSpot contact, tag them as “Lead – Free Consult”, and send a Slack notification to the sales channel.

Define the trigger
- Platform: Webflow Forms
- Event: Form Submission
- Test: Submit the form yourself to capture a sample payload.
Map the data
- Identify fields you need: email, first_name, company.
- In Zapier, use the “Customize Contact” step to map these fields to HubSpot fields.
Add the action
- App: HubSpot – Create Contact
- Set static tag Lead – Free Consult.
Enrich (optional)
- Insert an AI step (OpenAI) to generate a short intro paragraph based on the company description.
- Store the paragraph in a hidden field for later use.
Final action – Notification
- App: Slack – Send Channel Message
- Message template: 🆕 New free‑consult lead: {{first_name}} ({{email}}) – {{company}}.

Quick‑Test Checklist

[ ] Trigger fires with real data (check Zapier’s Test Trigger).
[ ] All required fields are mapped (no empty values).
[ ] Action succeeds without errors (HubSpot contact appears).
[ ] Notification lands in the correct Slack channel.
[ ] Turn the Zap on and monitor the first 5 live runs.

If any step fails, use the platform’s built‑in log to inspect the payload and adjust the mapping.

5. Scaling: From One Workflow to a Library of Templates

Once you have a reliable pattern, replicate it across departments. The guide provides 15 plug‑and‑play templates; here are three that often unlock the biggest ROI for small teams:

Template	Core Trigger	Primary Action	Typical Owner
Lead Capture → CRM → Slack	New form entry (Webflow, Typeform)	Create/Update contact; send Slack alert	Sales / Marketing
Invoice Reminder	Invoice status = Past Due in QuickBooks	Send email reminder; add task in Asana	Finance
Calendar Sync	New event in Google Calendar with `#client‑meeting` tag	Create meeting record in Airtable; send Zoom link via Gmail	Operations

Self‑Reflection Maturity Quiz (excerpt)

Question	Yes/No
Do we have a documented list of all repetitive tasks?
Are our key data sources (CRM, accounting) already in the cloud?
Does someone own the automation governance (updates, error handling)?
Have we defined success metrics (time saved, error reduction)?

If you answer No to more than two questions, pause scaling and address the gaps first.

6. Adding AI – When and How to Layer Intelligence

AI can turn a static automation into a knowledge‑enhancing workflow. Use AI when you need:

Content generation – draft email replies, write product descriptions.
Data enrichment – summarise long customer notes, classify sentiment.
Decision support – rank leads based on a custom scoring model.

Practical example: After a lead is captured, send the raw notes to an OpenAI model that outputs a 2‑sentence summary and a “lead score”. Store these in Airtable and use a filter to route high‑score leads to a sales‑call task.

Ethical guardrails:

Keep the prompt transparent for audit.
Store the AI‑generated text separately from source data.
Review outputs regularly to avoid drift.

7. Measuring Impact – KPI Dashboard & ROI Calculator

Automation is only worth the effort if you can see the results. Set up a simple dashboard (Airtable + Chart.js or Google Data Studio) with these core KPIs:

KPI	Definition	Target (first 3 months)
Automation Coverage	% of repetitive tasks automated	30 %
Time Saved (hrs/week)	Sum of estimated manual time replaced	20 hrs
Error Rate	Manual error incidents per month	↓ 70 %
Cost per Automation	Subscription cost ÷ number of automations	<$5

ROI formula:

ROI = (HourlyRate * TimeSaved – SubscriptionCost) / SubscriptionCost * 100%

Plug your hourly rate and the hours saved from the KPI dashboard to get a percentage. A positive ROI (> 0 %) validates the investment and fuels the next wave of automation.

8. Building an Automation‑First Culture

Automation succeeds when it becomes a habit, not a one‑off project. Adopt these rituals:

Weekly automation stand‑up – 15 min to review new requests, errors, and upcoming improvements.
Documentation sprint – every new workflow gets a one‑page “Run‑book” (trigger, steps, owner, KPI).
Continuous learning – allocate 1 hour/month for the team to explore a new Zapier/Make feature or a new template.

Over time, the organization will develop a feedback loop: identify bottlenecks → prototype → measure → iterate. This loop mirrors the classic Plan‑Do‑Check‑Act (PDCA) cycle, but with automation as the engine.

Conclusion

No‑code automation is no longer a futuristic buzzword; it’s a practical toolkit that lets small businesses reclaim hours, reduce errors, and scale without hiring engineers. By applying the diagnostic checklist, selecting the right platform with the comparison table, following the five‑step build framework, and measuring impact with a KPI dashboard, you can turn ad‑hoc scripts into a sustainable, growth‑focused automation culture.

Ready to dive deeper? The full guide contains detailed templates, AI integration patterns, and a complete ROI calculator you can copy‑paste into your own spreadsheet.

Read the full guide online for free: No‑Code Automation for Small Business Growth

We Crashed Lioran S3 5 Times While Writing 100 GiB. Here Are the Raw Logs.

Swaraj Puppalwar — Thu, 01 Oct 2026 18:23:48 +0000

We Crashed Lioran S3 5 Times While Writing 100 GiB. Here Are the Raw Logs.

Building storage infrastructure is easy when everything works.

The interesting part starts when you kill the server in the middle of a write.

So before launching Lioran S3 / Lioran Bastion V1 Pre-Alpha, I wanted something more useful than a screenshot of a benchmark terminal.

I wanted the raw evidence.

On September 30, 2026, I ran a 100 GiB storage workload and chaos test against Lioran S3.

The test:

wrote more than 100 GiB of objects,
distributed them across 15 buckets,
used 32 concurrent writers,
deliberately terminated the server 5 times,
restarted the same storage engine against the same dataset,
continued writing,
read the complete dataset back,
and finally performed SHA-256 integrity verification.

The complete logs from that run are publicly available.

No cropped benchmark screenshots.

No manually rewritten numbers.

The raw logs, manifests, metrics, crash events, recovery events, and integrity verification are linked at the bottom of this article.

What is Lioran S3?

Lioran S3, also known internally as Lioran Bastion, is an object-storage engine written primarily in Rust.

It is being developed by Lioran Developer Solutions (LDS) under Lioran Group.

I'm Swaraj Puppalwar, Founder & CTO of Lioran Group.

Lioran S3 V1 Pre-Alpha launched on October 1, 2026.

The goal of the project is not to produce another wrapper around an existing object-storage service.

The storage engine itself handles physical object placement, streaming I/O, metadata, integrity checks, multipart uploads, range reads, durability modes, media workloads, access control, and recovery behavior.

This test was designed to attack one of the most important questions:

What happens when the storage server disappears while data is actively being written?

Test configuration

The benchmark configuration recorded in the test artifact was:

Target dataset:       100 GiB
Buckets:              15
Write concurrency:    32
Read concurrency:     32
Scheduled crashes:    5
Chaos mode:           enabled
Upload timeout:       120 seconds
Write target:         500 MB/s
Read target:          500 MB/s

The workload used the same source asset repeatedly with unique object keys.

The source object was:

Size:     17,839,845 bytes
SHA-256:  d6617a009c0c6c9aebf7398d43cad6d1985ddc1b9ab0479e2ea977362b8af5b0

The final benchmark ran for approximately:

1631.7 seconds
≈ 27 minutes

from workload start through the final integrity phase.

Phase 1: Write 100 GiB

The write phase eventually stored:

100.52 GiB
107,931,062,250 bytes
6,050 successful objects

with:

Write concurrency:        32
Write duration:            1236.1 seconds
Average throughput:        87.3 MB/s
Healthy throughput:        88.5 MB/s
5-second peak throughput:  663.2 MB/s

Latency distribution:

p50:   4316.5 ms
p90:  12823.8 ms
p95:  13386.9 ms
p99:  15016.0 ms

The important number here is not the 663 MB/s peak.

A short peak is not sustained throughput.

The sustained average for the complete write phase was approximately 87.3 MB/s.

That distinction matters when publishing storage benchmarks.

Then we started killing the server

Chaos mode scheduled five abrupt server terminations at different points in the write workload.

The crash log records them at approximately:

Crash 1: 10.00 GB acknowledged progress
Crash 2: 27.02 GB acknowledged progress
Crash 3: 45.01 GB acknowledged progress
Crash 4: 68.00 GB acknowledged progress
Crash 5: 85.00 GB acknowledged progress

These were not graceful shutdowns.

The harness terminated the exact Bastion server process.

For example:

[CHAOS] Triggering scheduled server crash 1/5 at 10.00 GB acknowledged progress
[CHAOS] Executing abrupt server termination on exact PID 28980...

The same process was repeated five times during the workload.

Crash #1

The first server termination happened at approximately:

10.00 GB

After termination, the harness restarted Bastion against the existing data directory.

The recovery log recorded:

Server restored and healthy after 163.2ms
Total downtime: 2372ms

The SDK transport was then rebuilt and authenticated again.

serverGen=1
clientGen=1
rebuilds=1
authenticated=YES

The workload continued.

Crash #2

The second termination happened at:

27.02 GB

The storage engine restarted against the same dataset.

Recorded server recovery:

155.7ms

with total recorded downtime of approximately:

2339ms

The client was rebuilt again and the workers were released.

Crash #3

The third crash happened at:

45.01 GB

This recovery was slower.

The server health recovery measurement was:

3413.8ms

with total recorded downtime around:

6117ms

This is exactly why publishing only the fastest recovery number would be misleading.

Recovery time varied between crashes.

Crash #4

The fourth forced termination happened at:

68.00 GB

The server was restarted again against the existing storage directory.

The workload continued rather than starting from an empty dataset.

Crash #5

The final forced crash occurred at:

85.00 GB

After the fifth recovery, the workload continued until the target dataset was reached.

The final chaos result was:

Crashes requested:             5
Crashes completed:             5
Crash-related write drops:     155
Unexpected errors:             0
Recovery status:               ALL CRASHES RECOVERED

Those 155 dropped writes were expected consequences of deliberately killing the process while requests were in flight.

They were classified separately from unexpected write failures.

The final dataset

After all five crashes, Lioran S3 reached:

100.52 GiB

stored across:

15 buckets
6,050 successful objects

The workload recorded:

Unexpected write failures: 0
Retries:                   0

This does not mean requests were magically unaffected by crashes.

The logs explicitly record:

155 chaos-expected write drops

The distinction is important.

Expected failures caused by intentionally terminating the server are not the same thing as unexplained storage-engine failures.

Phase 2: Read everything back

Writing data is only half of a storage benchmark.

The next phase read the stored dataset.

Total:

Data read:          100.52 GiB
Read operations:    6,050
Concurrency:        32
Duration:           383.1 seconds

Measured throughput:

Average:            281.7 MB/s
5-second peak:      414.1 MB/s

Read latency:

p50:  1879.5 ms
p90:  2488.8 ms
p95:  2738.2 ms
p99:  8779.2 ms

And:

Unexpected read failures: 0
Retries:                  0

We did not hit the configured 500 MB/s read target

This is worth stating directly.

The test configuration specified:

Read target: 500 MB/s

The recorded sustained read throughput was:

281.7 MB/s

and the recorded 5-second peak was:

414.1 MB/s

Therefore this run did not achieve the configured 500 MB/s read target.

The machine, filesystem, workload, implementation, and test harness all influence these numbers.

Pre-alpha benchmarking should expose that instead of hiding it.

There is more optimization work to do.

Memory usage

The benchmark also tracked process memory.

The recorded values were:

Peak RSS:   924.2 MB
Final RSS:  231.7 MB

while operating on a dataset larger than:

100 GiB

The object engine uses streaming I/O rather than loading the complete dataset or complete large objects into memory.

Dataset size and process memory therefore do not need to scale together linearly.

The most important phase: integrity verification

Performance is irrelevant if the recovered data is wrong.

After the write and read workloads completed, the test harness performed SHA-256 verification against sampled stored objects.

The integrity phase verified:

188 objects

and reported:

Checksum failures:  0
Missing objects:    0

The final integrity log ends with:

Final verification complete:
188 verified,
0 checksum failures,
0 missing objects.
Result: PASS

The benchmark summary reports:

Integrity Verification: PASS
Missing Objects:        0
Corrupt Objects:        0
SHA-256 Mismatches:     0
Overall Result:         PASS

That is the result I care about more than the peak throughput graph.

Final result

The complete run finished with:

Dataset:                   100.52 GiB
Objects:                   6,050
Buckets:                   15

Scheduled crashes:         5
Completed crashes:         5
Crash write drops:         155
Unexpected write errors:   0
Unexpected read errors:    0

Average write:             87.3 MB/s
5s write peak:             663.2 MB/s

Average read:              281.7 MB/s
5s read peak:              414.1 MB/s

Peak RSS:                  924.2 MB
Final RSS:                 231.7 MB

Integrity samples:         188
Missing objects:           0
Corrupt objects:           0
SHA-256 mismatches:        0

Overall result:            PASS

Don't trust the summary. Inspect the evidence.

A benchmark summary is still produced by the benchmark harness.

So I'm publishing the underlying artifacts too.

You can inspect the crash timestamps, server output, individual writes, reads, recovery events, metrics, object manifest, and SHA-256 verification yourself.

Raw proof files

Human-readable benchmark summary

https://liorans3.sbs/proof/summary.txt

This is the quickest artifact to inspect.

Machine-readable benchmark summary

https://liorans3.sbs/proof/summary.json

Contains the structured configuration, throughput, latency percentiles, crash recovery measurements, memory statistics, integrity results, and correctness flags.

Crash log

https://liorans3.sbs/proof/crashes.log

Contains all five scheduled server terminations and the acknowledged dataset progress at which each crash occurred.

Recovery log

https://liorans3.sbs/proof/recovery.log

Contains server restart events, recovery timing, SDK transport reconstruction, authentication restoration, and workload release after each crash.

Integrity verification log

https://liorans3.sbs/proof/integrity.log

Contains individual SHA-256 verification operations and the final integrity result.

Write log

https://liorans3.sbs/proof/writes.log

Contains the write workload events used to build the dataset.

Read log

https://liorans3.sbs/proof/reads.log

Contains the read workload events for the completed dataset.

Server log

https://liorans3.sbs/proof/server.log

Raw server-side output captured during the benchmark and crash/recovery workload.

Test harness log

https://liorans3.sbs/proof/test.log

Contains the orchestration and lifecycle output from the benchmark harness.

Errors log

https://liorans3.sbs/proof/errors.log

The provided artifact from this run is empty.

That file is intentionally still published as part of the evidence bundle.

Object manifest

https://liorans3.sbs/proof/manifest.jsonl

The object-level JSONL manifest generated by the workload.

This is one of the larger artifacts and allows the run to be inspected at a much lower level than the summary.

Raw metrics

https://liorans3.sbs/proof/metrics.jsonl

Machine-readable JSONL metrics collected throughout the workload.

This is the largest proof artifact in the bundle and contains the time-series benchmark measurements used during the run.

Why publish all of this?

Because infrastructure benchmarks are extremely easy to make impressive.

Choose the fastest five seconds.

Use warm cache.

Ignore failed requests.

Disable durability.

Hide recovery behavior.

Crop the terminal.

Put a giant number on a landing page.

Done.

That is not what I want Lioran S3 engineering to become.

If I publish:

87.3 MB/s average writes

you should be able to inspect where that number came from.

If I say:

5 server crashes

you should be able to see all five crash timestamps.

If I say:

0 SHA-256 mismatches

you should be able to open the integrity log.

And when a configured target is missed, such as the 500 MB/s read target in this run, that should be visible too.

What this test proves, and what it does not

This run provides evidence that this specific Lioran S3 pre-alpha build, under this specific workload and environment, completed a 100.52 GiB write/read chaos test with five scheduled server terminations and finished the test harness's integrity checks without a detected missing or corrupted object.

It does not prove that Lioran S3 can never lose data.

It does not prove that every hardware configuration will achieve these throughput numbers.

It does not prove that every possible crash point has been tested.

It does not prove production readiness.

This is V1 Pre-Alpha.

The point of publishing the evidence is precisely to avoid turning one successful chaos run into a universal reliability claim.

What's next

This test exposed both strengths and obvious optimization targets.

The engine recovered from all five scheduled crashes and completed the integrity phase successfully.

At the same time, sustained throughput remains below the long-term targets, particularly on the read side of this run.

The next versions will continue focusing on:

storage-engine correctness,
crash consistency,
recovery,
throughput,
tail latency,
multipart workloads,
larger datasets,
longer-running workloads,
and more aggressive failure injection.

Lioran S3 V1 Pre-Alpha launched on October 1, 2026.

The next planned version is scheduled for November 17, 2026.

This is still early infrastructure.

But now the benchmark claims come with receipts.

Failure Windows in Lioran S3 V1: What the Current Rust Commit Pipeline Guarantees

Swaraj Puppalwar — Thu, 01 Oct 2026 17:51:49 +0000

Failure Windows in Lioran S3 V1

Storage-engine design becomes interesting at the word:

crash.

Happy-path code is only half the system.

The current Lioran S3 V1 Pre-Alpha write path has a clear sequence of staging, promotion, metadata commit, and rollback. That sequence also defines its failure windows.

I’m Swaraj Puppalwar, Founder & CTO of Lioran Group and Lioran Developer Solutions.

This article describes the current implementation, including where future hardening can go deeper.

Current normal PUT sequence

The implementation today is:

1. validate bucket/key
2. check capacity/quota
3. create staging file
4. stream payload + SHA-256
5. flush
6. fsync in strict mode
7. close staging file
8. re-check capacity/quota
9. create final parent directory
10. rename staging → final object path
11. build ObjectMetadata
12. write metadata to RocksDB
13. if metadata write fails, remove final payload
14. return success

The most important ordering detail is:

physical promotion
BEFORE
metadata commit

Why document the real ordering?

An architecture document may describe an intended invariant at a higher level.

The source code is what defines the current executable behavior.

For pre-alpha infrastructure, publishing the actual order is more useful than pretending the engine has already reached its final crash-consistency model.

Failure during streaming

If reading from the incoming stream fails:

staging file is removed
metadata was never committed
object is not visible as committed

That is a clean failure case.

Failure after streaming but before promotion

Capacity/quota checks can still reject the upload after its exact size is known.

The staging file is removed.

Again, no committed metadata has been created.

Rename failure

If:

fs::rename(staging, final)

fails, the operation returns a storage error and attempts staging cleanup.

Metadata has not yet been committed.

Metadata write failure

This case is more interesting.

At that moment:

physical payload has already been promoted
metadata has not successfully committed

The implementation responds by removing the physical payload:

fs::remove_file(&abs_path)

This is application-level rollback.

Process crash between rename and metadata

Now consider an uncontrolled process termination exactly after physical rename but before metadata commit.

The rollback code does not execute because the process is gone.

That can theoretically leave physical bytes without a corresponding metadata record.

This is a classic cross-resource atomicity problem:

filesystem namespace
+
embedded metadata database

are not one shared transaction.

Why this matters

Normal reads begin from metadata.

So an unreferenced physical file is not automatically exposed as a committed object.

But it can become orphaned disk usage.

That is different from exposing partial data, but it is still a recovery concern.

The inverse ordering has its own problem

Suppose metadata were committed first and the process died before physical promotion.

Then metadata could point to missing physical bytes.

That is usually worse for read correctness.

This is why robust storage systems often introduce additional durable intent/state machinery instead of pretending two independent persistence domains can be made atomic with ordering alone.

V1's current strategy

The current code uses:

staging
strict/balanced durability
atomic filesystem rename semantics where supported
metadata status checks
rollback on synchronous metadata failure
logical/physical separation

It does not magically turn filesystem + RocksDB into one atomic transaction.

That would be an inaccurate claim.

Future hardening direction

A stronger recovery protocol could involve concepts such as:

durable publish intent
recovery journal
startup reconciliation
orphan scanning
transaction state records
idempotent repair

Those are design directions, not claims about the current V1 implementation.

Why pre-alpha is the right time to discuss this

Pre-alpha should expose uncomfortable edge cases.

That is the phase for:

kill -9
power-loss simulation
disk-full testing
metadata failure injection
rename failure injection
orphan detection
checksum verification
restart loops

The purpose is not to prove the code never fails.

The purpose is to make every failure state defined and recoverable.

Correctness before architecture theater

Distributed replication would not remove this local commit problem.

It could multiply it.

That is why Lioran S3 intentionally focuses on single-node correctness before adding clustering and consensus layers.

A storage engine becomes trustworthy when its failure states are boring, documented, testable, and repairable.

That is the target.

Measuring the Rust Storage Engine: Lioran S3 PUT Timing from Network to RocksDB

Swaraj Puppalwar — Thu, 01 Oct 2026 17:51:12 +0000

Measuring the Lioran S3 Rust Storage Engine

A benchmark that says:

WRITE: 400 MB/s

creates more questions than it answers.

Where did time go?

Network?

SHA-256?

Filesystem writes?

fsync?

Directory creation?

Rename?

RocksDB metadata?

Lioran S3's normal PUT path contains explicit timing instrumentation for these stages.

I’m Swaraj Puppalwar, Founder & CTO of Lioran Group / Lioran Developer Solutions.

Enabling detailed PUT traces

The engine checks:

BASTION_TRACE_PUT_TIMINGS

Accepted truthy forms include values such as:

1
true
yes

The setting is cached in an atomic so the environment is not reparsed on every request.

Streaming timings

stream_to_staging measures:

recv_duration
write_duration
sha256_duration
flush_duration
fsync_duration
total_stream_duration

Then the outer PUT path adds:

close_duration
mkdir_duration
rename_duration
metadata_duration
total_duration

A conceptual trace

A PUT can therefore be decomposed like:

TOTAL PUT
├── receive from AsyncRead
├── SHA-256
├── staging writes
├── flush
├── fsync
├── close
├── mkdir
├── rename
└── RocksDB metadata commit

This is exactly the decomposition you want when tuning a storage engine.

Case 1: receive dominates

Suppose:

recv_ms      900
write_ms     100
sha256_ms     30
fsync_ms      20
metadata_ms    2

The server is mostly waiting for incoming bytes.

Optimizing RocksDB will not magically fix that.

Investigate:

client upload speed
network
TLS
reverse proxy buffering
request-body behavior

Case 2: fsync dominates

Suppose:

recv_ms      100
write_ms      80
fsync_ms     700

Now durability synchronization is expensive.

Questions include:

storage device latency
filesystem
virtualization
durability mode
write cache behavior

Case 3: metadata dominates

If:

metadata_ms

grows significantly under load, inspect the metadata path:

RocksDB compaction
WAL behavior
block cache
write stalls
disk contention
concurrent metadata operations

Case 4: hashing matters

SHA-256 is calculated incrementally on every incoming chunk.

At very high throughput, checksum CPU cost can become measurable.

That does not mean “remove checksums”.

It means measure the actual cost before inventing a bottleneck.

Aggregated metrics

LocalObjectStore also owns:

Arc<PutMetrics>

and records successful and failed PUT performance.

This lets the engine expose more than one request's anecdote.

Why high-resolution timing matters

Without stage timings, developers often optimize whatever subsystem they personally distrust.

Database engineer:

must be RocksDB

Networking engineer:

must be TLS

Systems engineer:

obviously fsync

The stopwatch is less political.

Benchmark contract

When publishing Lioran S3 numbers, record:

CPU
RAM
disk
filesystem
operating system
container/native
network topology
reverse proxy
TLS
object size distribution
concurrency
durability mode
software commit/version

Otherwise two benchmark runs may not be measuring the same system.

Optimization order

A sane loop is:

measure
  ↓
identify dominant stage
  ↓
change one thing
  ↓
measure again

not:

change 14 knobs
  ↓
number improved
  ↓
no idea why

Lioran S3's timing instrumentation exists so performance work can stay evidence-driven.

DEV Community: Swaraj Puppalwar

Introducing LioranDB Cloud Dedicated Instances: 2 vCPU, 4 GiB RAM & 150 GB Storage for Just ₹8/Hour

What Do You Get for ₹8/Hour?

Dedicated CPU and Memory Resources

150 GB of Storage

4 Internal Nodes and 8 Partitions

Daily Backups With 7-Day Retention

Simple, Hourly Pricing

Who Is This Plan For?

Building India's Developer Infrastructure 🇮🇳

Try LioranDB Cloud

[Boost]

LioranDB v2 Alpha Is Here! 15+ Days in Production, 15K Ops/sec, and Our First Cloud Users

LioranDB v2 Alpha Is Here! 15+ Days in Production, 15K Ops/sec, and Our First Cloud Users

15+ Days of Production Testing Without a Crash

I Migrated My Own Backends From MongoDB to LioranDB

Performance Benchmarks: 15,000 Operations Per Second!

We Also Launched LioranDB Cloud Service (LCS)!

What's Next? LioranDB v2 Alpha Stable

Building India's Developer Infrastructure 🇮🇳

Thank You!

Building India's Own NoSQL Document Database | My 1.5-Year Journey with LioranDB 🇮🇳

Swaraj Puppalwar: A Marathi Interview About My Coding Journey at 15 | September 2023

Watch the Original Interview

My Programming Journey in 2023

Looking Back From 2026

Why I'm Preserving This Interview

Prompt Engineering for Business Decision‑Making: Mental Models and Practical Workflows

Introduction

1. The Bridge Mental Model – Prompt as a Translation Layer

Quick Checklist – Is Your Prompt a Strong Bridge?

2. Structuring Prompts for Clarity and Control

2.1 Role‑Play

2.2 Step‑by‑Step (S‑B‑S) Framework

2.3 Constraint Framing

Sample Prompt – Market‑Entry Risk Assessment

3. Boosting Insight Quality – Advanced Prompt Techniques

3.1 Few‑Shot Examples

3.2 Chain‑of‑Thought (CoT)

3.3 Self‑Critique Loop

4. Guardrails – Trustworthiness & Ethics Checklist

5. Embedding Prompts into Everyday Workflows

5.1 Low‑Code Integration

5.2 Decision‑Support Playbook Template

6. From Prompt to Decision – A Mini‑Case Study

7. Scaling Prompt Practices Across an Organization

Conclusion

I Found an Interview of Myself From 3 Years Ago. I Had No Idea What Was Coming.

Three years is a ridiculous amount of time

The funniest part

AI‑Powered Personal Knowledge Management: A Practical Blueprint for Knowledge Workers

Why Personal Knowledge Management Matters in the Age of Information Overload

1. The Four‑Layer PKM Mental Model

2. Designing a Flexible PKM Architecture

3. AI‑Enhanced Capture: From Reading to Raw Data

3.1 One‑Click Web Clipping

3.2 Turning Audio into Text

3.3 Instant Summarization with LLMs

4. Organizing with Knowledge Graphs and Embeddings

4.1 Atomic Note‑Taking

4.2 Semantic Enrichment

5. Quality, Trust, and Privacy Checklist

6. From Insight to Action: Automating Workflows

6.1 Task Generation Prompt

6.2 Reminder Bots

7. Scaling and Evolving Your PKM System

8. Quick‑Start Checklist (First 48 Hours)

Conclusion

From Manual to Automated: A Practical Blueprint for Small‑Business Owners

Why No‑Code Automation Is a Game‑Changer for Small Businesses

1. The Automation Mental Model: Trigger → Action → Enrichment

2. Diagnostic Checklist – Spotting Low‑Hanging Fruit

3. Choosing the Right No‑Code Stack

4. Building Your First Automation – A 5‑Step Framework

Quick‑Test Checklist

5. Scaling: From One Workflow to a Library of Templates

Self‑Reflection Maturity Quiz (excerpt)

6. Adding AI – When and How to Layer Intelligence

7. Measuring Impact – KPI Dashboard & ROI Calculator

8. Building an Automation‑First Culture

8. Quick‑Start Checklist (First 48 Hours)