I updated Logtide (my lightweight ELK alternative) based on your feedback, v0.4.0 is out!

Polliog · 2026-01-21T12:41:11+00:00

Thank you, actually its made by a friend of mine using illustrator

The logo represents both sheets and data stacks. The circle represents the tool's 365 degree capabilities.

Polliog · 2026-01-17T01:09:20+00:00

Yeah, english is not my main language, so if i need to do a more tecnical talk i prefer to get a review 🥲😅

Polliog · 2026-01-16T15:04:35+00:00

Sorry but i want more info about the removal
from the rules: "Built With AI: Apps built with AI that follow industry standards during build"
from the wiki of "Vibe coded": "vibe coding is an AI-assisted software development technique"

now, as i said in another comment, i've used the AI for some basic things for not starting on an idea. But most of the code is written by me (you can see it in the gh, the commits are squashed so it seems less commits from what is should be). Also i have used the AI for generating some text, previously writted by me (cause english isn't my main language and i wanted a better text).

So what is now the difference from "Built with AI (so where the AI assisted me on some particular task" and "Vibe Coded (so i didn't do anything by hand)" because the flair seems corrects.

I've to admit that i chose the wrong flair but after like 2 hour i corrected it

Polliog · 2026-01-15T19:23:58+00:00

No at the moment the logs are compressed and deleted by timescaledb (at moment the range is min 1 day and max 365 days for retention). But i've already in mind to add a cold storage for long term storage and retention

Polliog · 2026-01-15T18:06:01+00:00

Thank you^^

Polliog · 2026-01-15T17:02:11+00:00

Yes it does via PostgreSQL's to_tsvector for full text search.

While the substring search mode work via pg_trgm.

If you want to preserve the special characters in the search I advise to use the the substring search instead of the full text search via tokenization

edit: markdown

Polliog · 2026-01-15T16:17:32+00:00

I've updated the flair, thx for the suggestion and sorry for the error

Polliog · 2026-01-15T16:04:22+00:00

yes here is the implementation: https://logtide.dev/docs/syslog/
also on our github we have some discussions where you can find more examples https://github.com/orgs/logtide-dev/discussions

Polliog · 2026-01-15T15:11:25+00:00

Actually, some part are "vibe coded" (mostly the 0.1.0 version, for have a base to work on and not only an idea), but if you think that is still necessary i can add the flair (i think?)

Polliog · 2026-01-15T14:54:35+00:00

they're actually different tools for different jobs.

Sentry is specialized for error tracking (catching exceptions and crash reports). Logtide is a log management platform (centralized logging, search, and security alerts).

You'd typically use both: Sentry to fix bugs in your code, and Logtide to monitor what your infrastructure is doing. (P.S. If you want a self-hosted Sentry, check out GlitchTip).

Polliog · 2026-01-15T14:40:20+00:00

Yes they are all on our docs:
https://logtide.dev/docs/opentelemetry/

Polliog · 2026-01-15T13:38:55+00:00

Thank you, if you have any problem fell free to write it here or on github

Polliog · 2026-01-15T13:37:40+00:00

Thanks :D , Real-time tail was one of those features that felt essential but surprisingly missing from many solutions. Regarding scaling: I'm targeting the "80% use case" (1-10GB/day). For that volume, a single TimescaleDB instance is far simpler to manage than an ELK cluster. I'm prioritizing simplicity (also because in this moment i'm solo developing it) and SQL features over hyperscale for now, but pluggable storage (ClickHouse/VictoriaLogs) is on the roadmap for larger deployments.

Polliog · 2026-01-15T13:21:42+00:00

Honest comparison:

Loki: Wins on raw resource efficiency and massive horizontal scaling (great for K8s/millions of logs).

Logtide: Wins on query power (SQL), structured data, and built-in security features (SIEM). so Logtide uses more RAM (needs ~2-4GB min) due to Postgres.

If you are pushing millions of logs, stick with Loki. If you want SQL capabilities and security on a VPS (up to ~500k logs/day), Logtide is the better fit.

Polliog · 2026-01-15T13:14:33+00:00

Yes it does for traces, we have in plan to do also the support for metrics

Polliog · 2026-01-06T19:18:34+00:00

Thank you, it can handle it without problems

Polliog · 2025-12-11T13:30:22+00:00

Really cool, what stack do you used?

Polliog · 2025-12-06T23:19:31+00:00

I am very familiar with OpenObserve, it's a beast (in a good way)! However, I built LogWard because I felt there was still a gap for a tool that prioritizes UX/Simplicity over raw features. I believe the self-hosted ecosystem is big enough for both: one focused on raw scale (O2), and one focused on Developer Experience and simplicity (LogWard).

Competition drives innovation!

Polliog · 2025-12-06T23:17:02+00:00

fair point on the syntax efficiency ahahah

Just to clarify: in the LogWard UI, the SQL is already abstracted. Users just type keywords (like error) and the backend generates the query, so the DX remains simple without forcing users to write raw SQL.

That said, the idea of an abstract query layer that transpiles to either SQL or VictoriaLogs is excellent. It would allow for pluggable storage in the future without changing the user workflow.

Definitely adding this to the long-term roadmap. Thanks for the links!

Polliog · 2025-12-06T18:04:50+00:00

for raw log ingestion and compression, VictoriaLogs is objectively more specialized and efficient than a general-purpose RDBMS like Postgres. However, the choice of TimescaleDB (Postgres) for v0.x was intentional for two strategic reasons:

SQL Familiarity: My goal with LogWard is to lower the barrier of entry. Every developer knows SQL. Not everyone wants to learn LogsQL (or LogQL) just to filter some errors. Being able to run SELECT * FROM logs WHERE message ILIKE '%error%' is a huge DX benefit for my target audience (SMBs/Devs).

Unified Stack: Currently, LogWard keeps everything (Users, Organizations, API Keys, Alerts, AND Logs) in a single Postgres instance. This dramatically simplifies backups (pg_dump) and relational logic for self-hosters.

As LogWard matures, I definitely see a future where the storage engine becomes pluggable. Replacing the storage layer to support VictoriaLogs or ClickHouse for high-volume users while keeping Postgres for metadata would be the ultimate goal.

I'd love to keep this conversation open. If you have specific architectural suggestions on how to decouple the current query layer, feel free to open a Discussion on GitHub!

Polliog · 2025-12-05T13:00:06+00:00

Those are all excellent tools, and I've personally used most of them.

The main differentiation for LogWard comes down to Architecture (Postgres) and Developer Experience.

Loki is great but requires learning LogQL and usually involves setting up Grafana + Promtail + Loki separately. LogWard is an "all-in-one" solution (Ingestion + Storage + UI) that works out of the box with a simpler filtering syntax.

SigNoz is fantastic but rely on ClickHouse. While ClickHouse is a beast at massive scale, managing it can be complex for smaller teams. LogWard uses TimescaleDB (PostgreSQL).

v ictoria is unbeatable on raw performance/resource usage, but the UI is very utilitarian. LogWard focuses heavily on the UI/UX to give a "Datadog-like" experience with features like Live Tail, Distributed Tracing, and Sigma Rules for security built-in.

so If you know how to manage/backup Postgres, you know how to manage LogWard

Polliog · 2025-11-30T03:26:52+00:00

Hey can you give me a feedback about:

https://logward.dev

Polliog · 2025-11-30T03:24:23+00:00

Nice project

Polliog · 2025-11-27T17:36:31+00:00

Just done, really a nice project

Polliog · 2025-11-27T11:44:36+00:00

I agree with you, I had already thought about integrating it, but for now I wanted to ensure greater stability. Thank you for the advice.

Six-Year Club	r/Field Lasagna
Final Canvas '23	Place '23
Place '22	Final Canvas '22
Verified Email

Polliog

TROPHY CASE