[HN Gopher] Show HN: Drop-in SQS replacement based on SQLite
___________________________________________________________________
Show HN: Drop-in SQS replacement based on SQLite
Hi! I wanted to share an open source API-compatible replacement for
SQS. It's written in Go, distributes as a single binary, and uses
SQLite for underlying storage. I wrote this because I wanted a
queue with all the bells and whistles - searching, scheduling into
the future, observability, and rate limiting - all the things that
many modern task queue systems have. But I didn't want to rewrite
my app, which was already using SQS. And I was frustrated that many
of the best solutions out there (BullMQ, Oban, Sidekiq) were
language-specific. So I made an SQS-compatible replacement. All
you have to do is replace the endpoint using AWS' native library in
your language of choice. For example, the queue works with Celery
- you just change the connection string. From there, you can see
all of your messages and their status, which is hard today in the
SQS console (and flower doesn't support SQS.) It is written to be
pluggable. The queue implementation uses SQLite, but I've been
experimenting with RocksDB as a backend and you could even write
one that uses Postgres. Similarly, you could implement multiple
protocols (AMQP, PubSub, etc) on top of the underlying queue. I
started with SQS because it is simple and I use it a lot. It is
written to be as easy to deploy as possible - a single go binary.
I'm working on adding distributed and autoscale functionality as
the next layer. Today I have search, observability (via
prometheus), unlimited message sizes, and the ability to schedule
messages arbitrarily in the future. In terms of monetization, the
goal is to just have a hosted queue system. I believe this can be
cheaper than SQS without sacrificing performance. Just as Backblaze
and Minio have had success competing in the S3 space, I wanted to
take a crack at queues. I'd love your feedback!
Author : memset
Score : 346 points
Date : 2024-06-30 15:11 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tjoff wrote:
| SQS: Amazon Simple Queue Service
| cwbrandsma wrote:
| Thank you, I was scratching my head trying to figure that out.
| rmbyrro wrote:
| Why some people think we need AI everywhere to "augment" and
| "enrich" our "experiences".
|
| People don't bother a google search, after, what, 20 years in
| town?
| jerrygenser wrote:
| > In terms of monetization, the goal is to just have a hosted
| queue system. I believe this can be cheaper than SQS without
| sacrificing performance. Just as Backblaze and Minio have had
| success competing in the S3 space, I wanted to take a crack at
| queues.
|
| are you monetizing this as a separate business from:
| https://www.ycombinator.com/companies/scratch-data
| memset wrote:
| Truthfully, I don't know yet - I haven't even built a
| paid/hosted version at all. It is related to my existing
| business in the sense that it deals with realtime data.
|
| But I started working this as something I wish existed as
| opposed to having some big VC strategy and pitch deck behind
| it.
|
| (Also, I appreciate all of your feedback on this a month ago!
| It was really helpful to encourage me to keep looking into this
| and also figuring out the "first" things to launch with!)
| Onavo wrote:
| What's the point of AGPL though? The enterprises with the
| budget for self hosting this sort of software usually have
| requirements and scale beyond what SQLite can offer out of the
| box.
| jerrygenser wrote:
| He's going to make backends pluggable. So other more scalable
| backends than sqlite could work
| memset wrote:
| In practice, I don't plan on adding an entire proprietary
| layer - that is just way too much work, and it defeats the
| purpose. If the open source code has bad performance, why
| would someone even bother with a hosted version? Like, I
| _want_ people to be so impressed by the open source code
| that they'd trust a cloud version to be even better.
| Clickhouse and duckdb do this very well.
|
| The main difference I expect with a hosted solution are
| things like multiple tenants or billing integrations. These
| aren't core to the product and only necessary when you need
| to host someone else's data.
| andrewstuart wrote:
| Ugh I didn't see that.
|
| My enthusiasm has instantly waned.
|
| Why is AGPL needed? Just be MIT and make it easy for people,
| espefcially if you're not planning on monetising it.
|
| I won't use AGPL code just on principle.
| sgarland wrote:
| This looks great! How were you planning on tackling distributed?
| memset wrote:
| This is a great question and something I've been thinking about
| a lot. Big picture:
|
| Each queue node can operate (mostly) independently, and this is
| good. As a consumer, I don't really care where my next message
| comes from, so I can minimize the amount of data that needs to
| have a "leader".
|
| The only data that needs to be synced is the list of queues,
| which doesn't change often. If one server is full, it should be
| able to route a request to another server.
|
| When we downscale, we can use S3/Dynamo (GCS/firestore) to
| store items and redistribute.
|
| There's more nitty gritty here (what about FIFO queues? What
| about replication?) but the fact that the main actions,
| "enqueue" and "dequeue", don't require lots of coordination
| makes this easier to reason about comapred to a full RDBMS.
| sgarland wrote:
| This would increase the complexity, but you could always run
| something like rqlite [0], even if only for the items that
| require distribution and synchronization.
|
| Or if you truly only need to store simple values in a
| distributed fashion, you could probably use etcd for that
| part.
|
| [0]: https://rqlite.io/
| flaminHotSpeedo wrote:
| You're hand-waving away all the complexity in the "nitty
| gritty."
|
| Enqueue absolutely requires coordination, if not via leader
| then at least amongst multiple nodes, if you want to
| guarantee at least once delivery
|
| If you don't guarantee that, cool, but you're not competing
| with sqs
| hrisen wrote:
| Keeping questions from scale & benchmarks aside, this is a cool
| thing for functional/unit testing module that uses SQS, instead
| of dumb mocks.
| memset wrote:
| Thank you! Yes, you should definitely use this instead of
| localstack :)
| thrauat wrote:
| Although I wouldn't recommend using LocalStack's SQS
| implementation for production workloads, calling it a dumb
| mock is a bit outdated. It emulates pretty much every SQS
| behvaior including long polling, delayed messages, visibility
| timeouts, DLQ redrive, batch send/receive, ...
| okr wrote:
| A testcontainer could be useful. I use always this adobe-mock
| from s3 for my test. Hmm.
| memset wrote:
| I was not aware of testcontainer until you just mentioned it! I
| have a very basic Dockerfile for deploying to fly.io. What/how
| would I get started?
|
| It looks like localstack is a supported testcontainer and they
| do support SQS (but I haven't tried it myself.)
| fbdab103 wrote:
| Minor thing - the gif browser demo should have been maximized.
| The video zooming into the action on what would have fit onto a
| single screen was distracting.
|
| Are there maintenance actions that the admin needs to perform on
| the database? How are those done?
| memset wrote:
| Thank you for the feedback - agree on the gif. Also it should
| probably show real messages an an example instead of rand().
|
| re: maintenance - I have tried to build this to be hands-off.
| The only storage this uses is SQLite, and I have the code set
| to automatically vacuum as space increases.
|
| It also has a /metrics endpoint which has disk size. This is
| going to be used for two things in the future: first, as a
| metric for autoscaling (scale when disk is full) and second so
| that a server can stop serving requests when its disk is full
| (to prevent catastrophic failure.)
| systemz wrote:
| Very cool. I needed something like this. Looking at short video
| in readme - I suspect adding live stats similar to sidekiq would
| make UI look more dynamic and allow quick diagnostics. Docs for
| current features are more important though.
| memset wrote:
| Can you tell me more about why you needed this (and what you
| ended up using?)
|
| Totally agree on adding more metrics and information to the UI
| - but how much of that should be on the dashboard vs exposed as
| a prometheus metric for someone to use their dashboard tool of
| choice?
|
| I am not very good at visual design and have chosen the
| simplest possible tech to build it (static rendering +
| fomanticUI). I sometimes wonder if the lack of react or
| tailwind or truly beautiful elements will hold the project
| back.
| stuaxo wrote:
| Good, we need open implementations of all the AWS stuff.
|
| I swear they reimplement stuff we have just so there are more
| places to bill us.
| memset wrote:
| Curious: if you were going to switch, how would you want to run
| this? Would you want to deploy it to your own EC2 instances, or
| would you want a hosted solution (just as SQS itself is?)
| stackskipton wrote:
| Self hosted probably. Why buy knock off SQS in the cloud when
| real thing is right there?
|
| If you are greenfield and scared of hitching yourself to
| Amazon, why not go something like RabbitMQ? There is also
| RabbitMQ cloud providers as well.
| jpalomaki wrote:
| Unless you need the features, I would steer away from the
| "real message queues". Running these adds complexity,
| especially if you want higher availability and they are not
| always cheap.
|
| HTTP based solution is easy to understand and implemented
| (if basic functionality is enough for your use case). Real
| MQs obviously have more complex protocols and not all
| client libraries are perfect.
| stackskipton wrote:
| I find basics of most AMQP systems to be extremely
| reliable. Message on, one time delivery with message
| hiding until expiration of TTL. Sure, you can get into
| some insane setups with RabbitMQ/Kafka and that's where
| libraries features don't always match up. But SQS
| probably wouldn't work for you either in those cases.
| nilamo wrote:
| Ideally this would be run within a k8s cluster, to easily fit
| with the other services.
| paulddraper wrote:
| SQS is cheap.
|
| 10m requests for $4.
|
| You will need hundreds of millions of requests per month for it
| to be noticable.
|
| And can an implementation like this even help you at that
| point?
| memset wrote:
| Question: is there any feature set (in contrast to pricing)
| that would make it worthwhile for someone to switch?
| threecheese wrote:
| Operations. At my $bigCo we are always rolling our own ops
| tooling for queues, as it's more than just "reprocess
| message"; there is always some business logic that
| separates different types of consumers/destinations, and so
| q management is never straightforward. Might be a
| differentiable feature.
| memset wrote:
| Can you tell me more about the types of queue things you
| need to implement? (Feel free to email me too - I'd be
| grateful for the feedback!)
| mlhpdx wrote:
| Not just cheap per message, but queues themselves are free so
| there is zero "reserved" cost - it's pay per message.
|
| Add to that, it's enormously scalable in terms of throughput
| and retained messages.
|
| And it's globally available.
|
| A single file app is no comparison, really. The value of SQS
| is in the engineering.
| yimpolo wrote:
| This is super cool! I love projects that aim to create simple
| self-hostable alternatives to popular services.
|
| I assume this would work without much issue with Litestream,
| though I'm curious if you've already tried it. This would make a
| great ephemeral queue system without having to worry about
| coordinating backend storage.
| memset wrote:
| I haven't tried this with litestream! It will be worth
| exploring that as a replication strategy.
|
| The nice thing about queues is that backend storage doesn't
| really need to be coordinated. Like, you could have two
| servers, with two sets of messages, and the client can just
| pull from them round robin. They (mostly) don't need to
| coordinate at all for this to work.
|
| However, this is different for replication where we have
| multiple nodes as backups.
| 12_throw_away wrote:
| Actually pretty excited to try this, there are so many cases
| where I need a bare-bones (aka "simple"), local, persistent
| queue, but all the usual suspects (amqp, apache whatever, cloud
| nonsense, etc.) are way too heavy.
|
| I'll probably try poking at it directly through the HTTP API
| rather than an SDK ... does it need AWS V4 auth signatures or
| anything?
| memset wrote:
| The only HTTP API that is exposed is actually the SQS one. (I'm
| not opposed to a "regular" HTTP API but the goal was to make it
| easy for people to use existing libraries.)
|
| If you do use your language's AWS SDK, the code handles [1] all
| of the V4 auth stuff.
| https://github.com/poundifdef/SmoothMQ/blob/main/protocols/s...
|
| I'd love your feedback! Particularly the difficulties you find
| in running it, of which I'm sure there are many, so I can fix
| them or update docs.
| stackskipton wrote:
| I'd also give a shout out to beanstalkd. I use it to teach
| message systems and it's great.
| 4RealFreedom wrote:
| The goals are a little different but I think it's worth pointing
| out ElasticMQ. I use it simulate sqs in a docker environment.
| https://github.com/softwaremill/elasticmq
| memset wrote:
| I have looked at elasticmq but not played with it myself. You
| might also be interested in their benchmarks of all of the
| existing queues out there: https://softwaremill.com/mqperf/
| julius wrote:
| I also just used ElasticMQ in a docker environment. Did you
| see any specific downsides, when you looked at it? In which
| scenarios should I consider replacing it with your solution?
| chromanoid wrote:
| Could you elaborate why you didn't choose e.g. RabbitMQ? I mean
| you talk about AMQP and such, it seems to me, that a client-side
| abstraction would be much more efficient in providing an exit
| strategy for SQS than creating an SQS "compatible" broker. For
| example in the Java ecosystem there is
| https://smallrye.io/smallrye-reactive-messaging/latest/ that
| serves a similar purpose.
| rmbyrro wrote:
| I'd have named it MQLite. Congrats on finishing and delivering a
| project, this is quite a challenge in itself. I think SQLite can
| be a great alternative for many kinds of projects.
| slotrans wrote:
| Not sure about the goal of providing a hosted service cheaper
| than SQS. SQS is already one of the cheapest services on Earth.
| It's pretty hard to spend more than a few bucks a month, even if
| you really try!
| memset wrote:
| That is fair. Two things to validate from a biz perspective:
|
| 1. Is there some threshold where this would make sense
| financially (n billions of messages.)
|
| 2. Are the extra developer features (ie, larger message sizes,
| observability, DAGs) worth it for people to switch?
|
| Would love your thoughts - what, if anything, would make you
| even entertain moving to a different queue system?
| GordonS wrote:
| Not the GP, but I also think you'll struggle to compete in
| the hosted service space.
|
| Maybe you could add a web admin GUI as a paid add on?
| threecheese wrote:
| What is your target market? Cloud-native is, like the
| commenter said, going to be difficult to differentiate based
| on cost. I can see this being useful for hybrid cloud (onprem
| instances), functional or local testing, "localfirst"
| workloads, enthusiasts etc.
| memset wrote:
| Now you sound like an investor :)
|
| My own vision is to take a queue that is relatively dumb
| and make it smarter. I want it to be able to, for example,
| allow you to rate limit workers without needing to
| implement this client side. And so on for all of the other
| bits that one needs to implement in the course of
| distributed processing.
|
| I'm still figuring out the market. Very large firms
| spending thousands of queues? Or developers who want a one
| stop solution built on familiar tech? Or hosting companies
| who want to offer their own queue as a service?
| mlhpdx wrote:
| I've heard this use case come up in hybrid new/legacy
| products where there is a chasm between legacy
| scalability (probably a monolith in the compute or
| storage layer, or both). The "new" side needs to be able
| to self-regulate and if you can put that into the
| service-side it would it would be a helpful transition
| enabler (and, let's face it, given these transitions
| often never finish your product would be effectively
| sticky).
|
| I don't think the cost of queues is a problem anywhere
| (I'm sure it is somewhere, but not a market's worth). The
| problems created by queues, on the other hand, are myriad
| and expensive.
| PanMan wrote:
| This depends on your definition of few.. but SQS costs us more
| than the servers handling the messages... It's cheap until you
| do billions of messages...
| skeeter2020 wrote:
| I love that we're seeing a lot of projects apply the KISS
| principal and leverage (or take inspiration) from SQLite, like
| this, PocketBase and even DuckDB. An entire generation of
| developers (including myself) were tricked into thinking you had
| to build for scale from day one, or worse, took the path of least
| resistance right to the most expensive place for cloud services:
| the middle. I'm hopeful the next generation will have their
| introduction to building apps with simple, easy to manage &
| deploy stacks. The more I learn about SQLite, the more I love it.
| memset wrote:
| Thank you for the kind words! I wanted to get _something_ out
| even if it doesn 't have the scalability stuff built. But I
| have been thinking and architecting that behind the scenes, and
| now I "only" need to turn it into code.
|
| I think the queue itself will end up using a number of
| technologies: SQLite for some data (ie, organizing messages by
| date and queue), RocksDB for other things (fast lookup for
| messages), DuckDB (for message statistics and metadata), and
| other data structures.
|
| I find that some of the most performant software often uses a
| mix of different data structures and algorithms by
| introspecting the nature of the data it has. And if I can make
| one node really sing, then I can have confidence that
| distributing that will yield results.
|
| I think SQLite is a great start, but I really do want the
| software to be able to utilize the full resources the
| underlying hardware.
| jmspring wrote:
| "build for scale", it really depends what needs to scale and
| what is "scale". Nearly every interview, every company these
| days thinks they need google or such level scaling. Nearly all
| do not.
| davidthewatson wrote:
| The whole idea here is superlative.
|
| +1 for k8s, kubernetes, cloud native, self-hosted, edge-enabled
| at low cost, no cost.
|
| I ran rq and minio for years on k8s, but been watching sqlite as
| a drop-in-replacement since most of my work has been early stage
| at or near the edge.
|
| Private cloud matters. This is an enabler. We've done too much
| already in public cloud where many things don't belong.
|
| BTLE sensors are perfectly happy talking to my Apple Watch
| directly with enough debugging.
|
| I'd argue the trip through cloud was not a win and should be
| corrected in the next generation of tools like this, where mobile
| is already well-primed for SQLite.
| memset wrote:
| Really interesting. Question: when it comes to running these
| software on k8s, do you prefer to manage and host yourself, or
| do you use managed solutions on top of your own infra? (Do you
| pay for minio support?)
|
| Asking from a business perspective - I of course intend to keep
| developing this, but am also really trying to think through the
| business case as well.
| davidthewatson wrote:
| Good question!
|
| The answer depends on funding, i.e. in my own never-leaves-
| my-house case it is always self-host, much like SOC work.
|
| In the case of startup or research lab work (day-job, for
| lack of a better descriptor). It's frequently a slice of AWS,
| GCP, or Azure, i.e. 6 figure/mo cloud bills.
|
| I think those two broad cases are worth considering.
| cpill wrote:
| k3s for on premises deployments. I'm also using it for local
| self hosting side projects.
| pfix wrote:
| rq as in Redis Queue?
| philippta wrote:
| One quick suggestion on project structure:
|
| Move all the structs from models/ into the root directory.
|
| This allow users of this package to have nice and short names
| like: q.Message and q.Queue, and avoids import naming conflicts
| if the user has its own ,,models" package.
| memset wrote:
| Thanks for the tip - and for even looking at the code! I always
| struggle to figure out how to organize things.
| philippta wrote:
| Just noticed that your root directory is already ,,package
| main" so you can either move that to /cmd/something/ or
| simply rename models/ to q/. That would have the same effect
| and is also idiomatic.
| pqb wrote:
| Actually, the "model/" (note: singular form) directory (package
| model) would be preferred in the golang world.
| mannyv wrote:
| So I assume it does the back-end as well?
|
| I never cared to figure out what parts of SQS are clients-side
| and server side, but - does SmoothMQ support long polling, batch
| delivery, visibility timeouts, error handling, and - triggers? Or
| are triggers left to whatever is implementing the queue? Both
| FiFo and simple queues? Do you have throughput numbers?
|
| As an SQS user, a table of SQS features vs SmoothMQ would be
| handy. If it's just an API-compatible front-end then that would
| be good to know. But if it does more that would also be good to
| know.
|
| The reason you'd use this is because there are lots of clients
| who still want on-prem solutions (go figure). Being able to
| switch targets this way would be handy.
| memset wrote:
| Everything here is on the backend. The client does very little
| except make api calls.
|
| It implements many of these features so far (ie, visibility
| timeouts) and there are some that are still in progress (long
| polling.) a compatibility table is a good idea.
| deskr wrote:
| Perhaps do a small example application. go get
| github.com/poundifdef/SmoothMQ/models go:
| github.com/poundifdef/SmoothMQ@v0.0.0-20240630162953-46f8b2266d60
| requires go >= 1.22.2; switching to go1.22.4 go:
| github.com/poundifdef/SmoothMQ@v0.0.0-20240630162953-46f8b2266d60
| (matching github.com/poundifdef/SmoothMQ/models@upgrade) requires
| github.com/poundifdef/SmoothMQ@v0.0.0-20240630162953-46f8b2266d60
| : parsing go.mod: module declares its path as: q
| but was required as: github.com/poundifdef/SmoothMQ
| memset wrote:
| Good idea! fyi this is not meant to be used as a library. It
| runs as a standalone server, and then your application connects
| to it using an existing AWS sdk.
| localfirst wrote:
| FYI, this has AGPL 3.0 licensing.
|
| When I see this I assume VC backed cloud monetization is in the
| works.
|
| We need to include license information in Show HN projects to
| save people time-- our company find non MIT/BSD license projects
| are problematic and needlessly complicates things.
| pvg wrote:
| The purpose of Show HN is not really 'product catalogue'
| localfirst wrote:
| i didnt ask for a product catalogue, all im asking is to
| clarify whether you are truly FOSS or not by being
| transparent about the license.
|
| Any type of licensing conditions like AGPL 3.0 to force you
| to share your code is a no go for many many companies.
|
| I understand the desire to make money and you can do that
| without AGPL 3.0
| bumbledraven wrote:
| It's right there in the LICENSE file:
| https://github.com/poundifdef/SmoothMQ/blob/main/LICENSE
|
| What's unclear or not transparent about that?
| localfirst wrote:
| All I'm asking is to include the type of license in the
| Show HN title
|
| I had no idea there would be so much push back against
| this.
| xchip wrote:
| Thanks!
|
| Loving all these self-hosted KISS stuff :)
| encoderer wrote:
| I think it's better to say it's sqs compatible versus an sqs
| replacement.
| pqdbr wrote:
| How would one use this to replace Sidekiq for instance?
|
| Rate limiting is something I miss on Sidekiq (only available on
| the premium plan that I can't afford) and the gems that extend it
| break compatibility often.
| koito17 wrote:
| I may be asking a naive question, but what is the rationale
| behind disabling foreign key support and using them anyway in the
| database schema? See
| https://github.com/poundifdef/SmoothMQ/blob/46f8b22/queue/sq...
|
| The "TODO: check for errors" comment, combined with what seems
| like disabling foreign key constraint checks, makes me a bit
| hesitant to try this out.
| memset wrote:
| Good question. It was an evolution. Originally I enforced
| foreign keys, but inserts/updates were unbearably slow. So I
| updated the connection string to disable them (but, as you
| point out, I haven't updated the CREATE TABLE statements.)
|
| In practice, I did not find they were necessary - I was only
| using foreign keys to automatically CASCADE deletes when
| messages were removed. But instead of relying on sqlite to do
| that, I do it myself and wrap the delete statements in
| transactions.
|
| There are many TODOs and error checkings that I will, over
| time, clean up and remove. I'm glad you've pointed them out -
| that's the great thing about open source, you at least _know_
| what you 're getting into and can help shine a light on things
| to improve!
| plasma wrote:
| Some of the slowdown will come from not indexing the FK
| columns themselves, as they need to be searched during
| updates / deletes to check the constraints.
| john-tells-all wrote:
| Why not use LocalStack? It has SQS and a _lot_ of AWS services
| for testing /development. Well documented, open source.
|
| https://docs.localstack.cloud/overview/
| crazysim wrote:
| I think the vibe might be that this is something someone could
| use for production.
| mihaitodor wrote:
| At the very least, I'm guessing this performs better since it's
| written in Golang.
| andrewstuart wrote:
| Because SIMPLE.
|
| single exectuable binary
|
| golang with sqlite so fast
|
| minimal config so no ridiculous hours or days of config and
| operations
|
| This blitzes other ideas for use cases that do not require
| distributed queues - and that is likely many use cases.
| neuroscisoft wrote:
| This is very interesting! The self-hosted aspect is something
| I'll have to consider for certain purposes.
|
| My lab also developed an SQS-esque system based on the
| filesystem, so no dependencies whatsoever and no need for any
| operational system other than the OS. It doesn't support all SQS
| commands (because we haven't needed them), but it also supports
| commands that SQS doesn't have (like release all messages to
| visible status).
|
| https://github.com/seung-lab/python-task-queue
| threecheese wrote:
| There is a lot of new ecosystem being built around SQLite in the
| browser using wasm, as a primary data store or as a local replica
| for every client, and there are some interesting interactions
| with crdt and peer to peer applications; does this fit into your
| business case? Would be interesting to see a massively
| distributed - via browser embedding - queue, that even uses
| standard sqs bindings.
| andrewstuart wrote:
| I wrote sasquatch which is similar. sasquatch is more simple than
| SQS and queues are virtual (i.e the queue exists because you put
| a message in it, and is gone when there's no messages in it).
|
| https://github.com/crowdwave/sasquatch
|
| sasquatch is also a message queue, also written in Golang and
| also based on sqlite.
|
| sasquatch implements behaviour very similar to SQS but does not
| attempt to be a dropin replacement.
|
| sqsquatch is not a complete project though, nor even really a
| prototype, just early code. Likely it does not compile.
|
| HOWEVER - sasquatch is MIT license (versus this project which is
| AGPL) so you are free to do with it as you choose.
|
| sasquatch is a single file of 700 lines so easy to get your head
| around:
| https://raw.githubusercontent.com/crowdwave/sasquatch/main/s...
|
| Just remember as I say it's early code, won't even compile yet
| but functionally should be complete.
| PanMan wrote:
| Correct me if I'm wrong but: SQLite sounds like: runs on one
| server. While that will work most of the time, it won't work 100%
| of the time. I don't know the specifics, but I'm fairly sure if a
| queue server crashes, SQS will keep working, as stuff is
| redundant. So while it can work in a best case, this (probably)
| won't have the same reliability as SQS has..
| memset wrote:
| I break it down two ways.
|
| First, the project does not yet have a distributed
| implementation, you're correct. Stay tuned!
|
| Second, SQLite is incidental. Data is still stored on disk,
| just as SQS must be, but I've chosen SQLite as the file format
| for now.
___________________________________________________________________
(page generated 2024-06-30 23:00 UTC)