Alternatives to RxDB logo

Alternatives to RxDB

MongoDB, Pouchdb, WatermelonDB, NeDB, and LokiJS are the most popular alternatives and competitors to RxDB.
49
144
+ 1
53

What is RxDB and what are its top alternatives?

💻 📱 Reactive, serverless, client-side, offline-first database in javascript. Client-Side Database for Browsers, NodeJS, electron, cordova, react-native and every other javascript-runtime.
RxDB is a tool in the Databases category of a tech stack.
RxDB is an open source tool with 16.9K GitHub stars and 808 GitHub forks. Here’s a link to RxDB's open source repository on GitHub

Top Alternatives to RxDB

  • MongoDB

    MongoDB

    MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...

  • Pouchdb

    Pouchdb

    PouchDB enables applications to store data locally while offline, then synchronize it with CouchDB and compatible servers when the application is back online, keeping the user's data in sync no matter where they next login. ...

  • WatermelonDB

    WatermelonDB

    WatermelonDB is a new way of dealing with user data in React Native and React web apps. It's optimized for building complex applications in React Native, and the number one goal is real-world performance. In simple words, your app must launch fast. ...

  • NeDB

    NeDB

    Embedded persistent or in memory database for Node.js, nw.js, Electron and browsers, 100% JavaScript, no binary dependency. API is a subset of MongoDB's and it's plenty fast. ...

  • LokiJS

    LokiJS

    LokiJS is a document oriented database written in javascript, published under MIT License. Its purpose is to store javascript objects as documents in a nosql fashion and retrieve them with a similar mechanism. Runs in node (including cordova/phonegap and node-webkit), nativescript and the browser. ...

  • Firebase

    Firebase

    Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds. ...

  • Apollo

    Apollo

    Build a universal GraphQL API on top of your existing REST APIs, so you can ship new application features fast without waiting on backend changes. ...

  • MySQL

    MySQL

    The MySQL software delivers a very fast, multi-threaded, multi-user, and robust SQL (Structured Query Language) database server. MySQL Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software. ...

RxDB alternatives & related posts

MongoDB logo

MongoDB

66.7K
56.1K
4.1K
The database for giant ideas
66.7K
56.1K
+ 1
4.1K
PROS OF MONGODB
  • 826
    Document-oriented storage
  • 591
    No sql
  • 548
    Ease of use
  • 465
    Fast
  • 407
    High performance
  • 256
    Free
  • 215
    Open source
  • 180
    Flexible
  • 143
    Replication & high availability
  • 110
    Easy to maintain
  • 42
    Querying
  • 38
    Easy scalability
  • 37
    Auto-sharding
  • 36
    High availability
  • 31
    Map/reduce
  • 27
    Document database
  • 25
    Full index support
  • 25
    Easy setup
  • 16
    Reliable
  • 15
    Fast in-place updates
  • 14
    Agile programming, flexible, fast
  • 12
    No database migrations
  • 8
    Enterprise
  • 8
    Easy integration with Node.Js
  • 6
    Enterprise Support
  • 5
    Great NoSQL DB
  • 3
    Drivers support is good
  • 3
    Aggregation Framework
  • 3
    Support for many languages through different drivers
  • 2
    Awesome
  • 2
    Schemaless
  • 2
    Managed service
  • 2
    Fast
  • 2
    Easy to Scale
  • 1
    Consistent
  • 1
    Acid Compliant
CONS OF MONGODB
  • 5
    Very slowly for connected models that require joins
  • 3
    Not acid compliant
  • 1
    Proprietary query language

related MongoDB posts

Jeyabalaji Subramanian

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Robert Zuber

We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

See more
Pouchdb logo

Pouchdb

111
206
5
Open-source JavaScript database inspired by Apache CouchDB that's designed to run well within the browser
111
206
+ 1
5
PROS OF POUCHDB
  • 1
    Offline cache
  • 1
    Very fast
  • 1
    JSON
  • 1
    Free
  • 1
    Repication
CONS OF POUCHDB
    Be the first to leave a con

    related Pouchdb posts

    Jonathan Pugh
    Software Engineer / Project Manager / Technical Architect · | 25 upvotes · 1.6M views

    I needed to choose a full stack of tools for cross platform mobile application design & development. After much research and trying different tools, these are what I came up with that work for me today:

    For the client coding I chose Framework7 because of its performance, easy learning curve, and very well designed, beautiful UI widgets. I think it's perfect for solo development or small teams. I didn't like React Native. It felt heavy to me and rigid. Framework7 allows the use of #CSS3, which I think is the best technology to come out of the #WWW movement. No other tech has been able to allow designers and developers to develop such flexible, high performance, customisable user interface elements that are highly responsive and hardware accelerated before. Now #CSS3 includes variables and flexboxes it is truly a powerful language and there is no longer a need for preprocessors such as #SCSS / #Sass / #less. React Native contains a very limited interpretation of #CSS3 which I found very frustrating after using #CSS3 for some years already and knowing its powerful features. The other very nice feature of Framework7 is that you can even build for the browser if you want your app to be available for desktop web browsers. The latest release also includes the ability to build for #Electron so you can have MacOS, Windows and Linux desktop apps. This is not possible with React Native yet.

    Framework7 runs on top of Apache Cordova. Cordova and webviews have been slated as being slow in the past. Having a game developer background I found the tweeks to make it run as smooth as silk. One of those tweeks is to use WKWebView. Another important one was using srcset on images.

    I use #Template7 for the for the templating system which is a no-nonsense mobile-centric #HandleBars style extensible templating system. It's easy to write custom helpers for, is fast and has a small footprint. I'm not forced into a new paradigm or learning some new syntax. It operates with standard JavaScript, HTML5 and CSS 3. It's written by the developer of Framework7 and so dovetails with it as expected.

    I configured TypeScript to work with the latest version of Framework7. I consider TypeScript to be one of the best creations to come out of Microsoft in some time. They must have an amazing team working on it. It's very powerful and flexible. It helps you catch a lot of bugs and also provides code completion in supporting IDEs. So for my IDE I use Visual Studio Code which is a blazingly fast and silky smooth editor that integrates seamlessly with TypeScript for the ultimate type checking setup (both products are produced by Microsoft).

    I use Webpack and Babel to compile the JavaScript. TypeScript can compile to JavaScript directly but Babel offers a few more options and polyfills so you can use the latest (and even prerelease) JavaScript features today and compile to be backwards compatible with virtually any browser. My favorite recent addition is "optional chaining" which greatly simplifies and increases readability of a number of sections of my code dealing with getting and setting data in nested objects.

    I use some Ruby scripts to process images with ImageMagick and pngquant to optimise for size and even auto insert responsive image code into the HTML5. Ruby is the ultimate cross platform scripting language. Even as your scripts become large, Ruby allows you to refactor your code easily and make it Object Oriented if necessary. I find it the quickest and easiest way to maintain certain aspects of my build process.

    For the user interface design and prototyping I use Figma. Figma has an almost identical user interface to #Sketch but has the added advantage of being cross platform (MacOS and Windows). Its real-time collaboration features are outstanding and I use them a often as I work mostly on remote projects. Clients can collaborate in real-time and see changes I make as I make them. The clickable prototyping features in Figma are also very well designed and mean I can send clickable prototypes to clients to try user interface updates as they are made and get immediate feedback. I'm currently also evaluating the latest version of #AdobeXD as an alternative to Figma as it has the very cool auto-animate feature. It doesn't have real-time collaboration yet, but I heard it is proposed for 2019.

    For the UI icons I use Font Awesome Pro. They have the largest selection and best looking icons you can find on the internet with several variations in styles so you can find most of the icons you want for standard projects.

    For the backend I was using the #GraphCool Framework. As I later found out, #GraphQL still has some way to go in order to provide the full power of a mature graph query language so later in my project I ripped out #GraphCool and replaced it with CouchDB and Pouchdb. Primarily so I could provide good offline app support. CouchDB with Pouchdb is very flexible and efficient combination and overcomes some of the restrictions I found in #GraphQL and hence #GraphCool also. The most impressive and important feature of CouchDB is its replication. You can configure it in various ways for backups, fault tolerance, caching or conditional merging of databases. CouchDB and Pouchdb even supports storing, retrieving and serving binary or image data or other mime types. This removes a level of complexity usually present in database implementations where binary or image data is usually referenced through an #HTML5 link. With CouchDB and Pouchdb apps can operate offline and sync later, very efficiently, when the network connection is good.

    I use PhoneGap when testing the app. It auto-reloads your app when its code is changed and you can also install it on Android phones to preview your app instantly. iOS is a bit more tricky cause of Apple's policies so it's not available on the App Store, but you can build it and install it yourself to your device.

    So that's my latest mobile stack. What tools do you use? Have you tried these ones?

    See more
    Mike Endale
    Shared insights
    on
    Android SDKAndroid SDKRealmRealmPouchdbPouchdb
    at

    We are building an offline-first Android SDK app. The solution we're working on runs on a mobile device in areas where internet connectivity is intermittent or does not exist. The applications needs to be able to collect data and when it reaches a home base or finds internet connectivity, we'll sync it with the host.

    We've heard Realm and Pouchdb could be a good solution, but we are curious if anyone has any experience with either or have another path forward.

    See more
    WatermelonDB logo

    WatermelonDB

    10
    96
    1
    🍉 Next-gen database for powerful React and React Native apps that scales to 10,000s of records and remains...
    10
    96
    + 1
    1
    PROS OF WATERMELONDB
    • 1
      Undefined is not an object (evaluating 'columnSchema.ty
    CONS OF WATERMELONDB
      Be the first to leave a con

      related WatermelonDB posts

      NeDB logo

      NeDB

      26
      71
      0
      Simple in-app or in-browser pure javascript database
      26
      71
      + 1
      0
      PROS OF NEDB
        Be the first to leave a pro
        CONS OF NEDB
          Be the first to leave a con

          related NeDB posts

          LokiJS logo

          LokiJS

          22
          40
          2
          In-memory JavaScript Datastore with Persistence
          22
          40
          + 1
          2
          PROS OF LOKIJS
          • 2
            Can query the objects directly
          CONS OF LOKIJS
            Be the first to leave a con

            related LokiJS posts

            Firebase logo

            Firebase

            29K
            24.8K
            1.9K
            The Realtime App Platform
            29K
            24.8K
            + 1
            1.9K
            PROS OF FIREBASE
            • 364
              Realtime backend made easy
            • 267
              Fast and responsive
            • 236
              Easy setup
            • 211
              Real-time
            • 188
              JSON
            • 132
              Free
            • 124
              Backed by google
            • 83
              Angular adaptor
            • 66
              Reliable
            • 36
              Great customer support
            • 29
              Great documentation
            • 24
              Real-time synchronization
            • 21
              Mobile friendly
            • 18
              Rapid prototyping
            • 14
              Great security
            • 12
              Automatic scaling
            • 11
              Freakingly awesome
            • 8
              Chat
            • 8
              Angularfire is an amazing addition!
            • 8
              Super fast development
            • 6
              Ios adaptor
            • 6
              Awesome next-gen backend
            • 5
              Firebase hosting
            • 5
              Built in user auth/oauth
            • 4
              Very easy to use
            • 4
              Speed of light
            • 3
              Brilliant for startups
            • 3
              Great
            • 3
              It's made development super fast
            • 2
              Free authentication solution
            • 2
              Push notification
            • 2
              The concurrent updates create a great experience
            • 2
              I can quickly create static web apps with no backend
            • 2
              Great all-round functionality
            • 2
              JS Offline and Sync suport
            • 2
              Low battery consumption
            • 1
              CDN & cache out of the box
            • 1
              Faster workflow
            • 1
              Free SSL
            • 1
              Easy to use
            • 1
              Large
            • 1
              Serverless
            • 1
              .net
            • 1
              Good Free Limits
            • 1
              Easy Reactjs integration
            • 1
              Free hosting
            • 1
              Cloud functions
            CONS OF FIREBASE
            • 29
              Can become expensive
            • 15
              No open source, you depend on external company
            • 15
              Scalability is not infinite
            • 9
              Not Flexible Enough
            • 5
              Cant filter queries
            • 3
              Very unstable server
            • 2
              No Relational Data
            • 2
              Too many errors
            • 2
              No offline sync

            related Firebase posts

            Stephen Gheysens
            Senior Solutions Engineer at Twilio · | 14 upvotes · 434.4K views

            Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

            My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

            See more
            Tassanai Singprom

            This is my stack in Application & Data

            JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB

            My Utilities Tools

            Google Analytics Postman Elasticsearch

            My Devops Tools

            Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack

            My Business Tools

            Slack

            See more
            Apollo logo

            Apollo

            1.9K
            1.5K
            18
            GraphQL server for Express, Connect, Hapi, Koa and more
            1.9K
            1.5K
            + 1
            18
            PROS OF APOLLO
            • 12
              From the creators of Meteor
            • 3
              Great documentation
            • 2
              Real time if use subscription
            • 1
              Open source
            CONS OF APOLLO
              Be the first to leave a con

              related Apollo posts

              Nick Rockwell
              SVP, Engineering at Fastly · | 44 upvotes · 1.8M views

              When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

              So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

              React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

              Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

              See more
              Adam Neary

              At Airbnb we use GraphQL Unions for a "Backend-Driven UI." We have built a system where a very dynamic page is constructed based on a query that will return an array of some set of possible “sections.” These sections are responsive and define the UI completely.

              The central file that manages this would be a generated file. Since the list of possible sections is quite large (~50 sections today for Search), it also presumes we have a sane mechanism for lazy-loading components with server rendering, which is a topic for another post. Suffice it to say, we do not need to package all possible sections in a massive bundle to account for everything up front.

              Each section component defines its own query fragment, colocated with the section’s component code. This is the general idea of Backend-Driven UI at Airbnb. It’s used in a number of places, including Search, Trip Planner, Host tools, and various landing pages. We use this as our starting point, and then in the demo show how to (1) make and update to an existing section, and (2) add a new section.

              While building your product, you want to be able to explore your schema, discovering field names and testing out potential queries on live development data. We achieve that today with GraphQL Playground, the work of our friends at #Prisma. The tools come standard with Apollo Server.

              #BackendDrivenUI

              See more
              MySQL logo

              MySQL

              88K
              71.9K
              3.7K
              The world's most popular open source database
              88K
              71.9K
              + 1
              3.7K
              PROS OF MYSQL
              • 793
                Sql
              • 673
                Free
              • 556
                Easy
              • 527
                Widely used
              • 485
                Open source
              • 180
                High availability
              • 160
                Cross-platform support
              • 104
                Great community
              • 78
                Secure
              • 75
                Full-text indexing and searching
              • 25
                Fast, open, available
              • 14
                SSL support
              • 13
                Reliable
              • 13
                Robust
              • 8
                Enterprise Version
              • 7
                Easy to set up on all platforms
              • 2
                NoSQL access to JSON data type
              • 1
                Relational database
              • 1
                Easy, light, scalable
              • 1
                Sequel Pro (best SQL GUI)
              • 1
                Replica Support
              CONS OF MYSQL
              • 14
                Owned by a company with their own agenda
              • 1
                Can't roll back schema changes

              related MySQL posts

              Tim Abbott

              We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

              We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

              And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

              I can't recommend it highly enough.

              See more
              Conor Myhrvold
              Tech Brand Mgr, Office of CTO at Uber · | 21 upvotes · 1.1M views

              Our most popular (& controversial!) article to date on the Uber Engineering blog in 3+ yrs. Why we moved from PostgreSQL to MySQL. In essence, it was due to a variety of limitations of Postgres at the time. Fun fact -- earlier in Uber's history we'd actually moved from MySQL to Postgres before switching back for good, & though we published the article in Summer 2016 we haven't looked back since:

              The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL (https://eng.uber.com/schemaless-part-one/). In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL:

              https://eng.uber.com/mysql-migration/

              See more